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Abstract 

The  failure  of  the  United  States  Air  Force’s  (USAF)  Expeditionary  Combat 
Support  System  (ECSS)  program  has  resulted  in  supply  chain  stakeholders  creating 
independent  solutions  in  a  complex  network  of  supply  chain  information  systems  (IS). 
The  decentralized  management  of  IS  has  led  to  stakeholders  optimizing  local  missions  to 
the  detriment  of  enterprise  level  goals  and  effectiveness.  This  case  study  evaluates  the 
Depot  Source  of  Repair  (DSOR)  team  and  how  it  has  addressed  the  USAF’s  enterprise- 
level  IS  deficiencies.  A  framework  created  from  the  literature  review  is  used  to  evaluate 
the  DSOR  team’s  IS  called  DSOR  II.  The  case  study  evaluation  identified  five  key 
managerial  implications  which  better  addresses  the  negative  impacts  of  USAF  IS 
deficiencies.  A  more  effective  IS  will  help  the  DSOR  team  manage  the  USAF’s  $13 
billion  depot  repair  program  more  effectively.  The  framework  introduced  in  this  report 
can  be  used  by  organizations  challenged  with  enterprise-level  IS  deficiencies. 
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ADDRESSING  ENTERPRISE-LEVEL 
INFORMATION  SYSTEM  DEFICIENCIES 

I.  Introduction 

This  research  examines  the  United  States  Air  Force  (USAF)  management  of  its  supply 
chain  infonnation  system  (IS)  network.  The  USAF  currently  employs  a  decentralized  approach 
to  the  management  of  its  supply  chain  IS  network.  This  section  contains  an  introduction  to  the 
USAF  supply  IS  network,  problem  statement,  purpose  and  the  assumptions  of  the  research. 

USAF  Supply  Chain  IS  Network 

The  USAF  has  been  operating  its  supply  chain  using  hundreds  of  independent  and 
outdated  software  programs,  commonly  referred  to  as  “legacy  systems”,  to  meet  its  mission 
requirements  (Hamilton,  2007).  The  USAF  determined  this  was  not  the  optimal  way  to  manage 
its  supply  chain  capabilities  and,  in  2004,  decided  to  follow  in  the  footsteps  of  many  successful 
private  organizations  in  adopting  an  Enterprise  Resource  Planning  (ERP)  system  to  streamline  its 
supply  chain.  The  USAF  initiated  the  acquisition  and  adoption  of  a  system  called  the 
Expeditionary  Combat  Support  System  (ECSS). 

ECSS  was  the  USAF’s  solution  to  an  outdated  and  sub-optimal  supply  chain  IS.  The 
ERP  system  was  designed  to  streamline  information  across  all  key  stakeholders  in  the  supply 
chain,  from  the  manufacturer  to  the  maintenance,  repair  and  overhaul  (MRO)  functions  to  the 
war-fighter  (Hamilton,  2007).  ECSS  would  eliminate  the  need  for  over  420  independent  IS  and 
be  the  focal  point  for  order  management,  purchasing,  inventory,  distribution  and  financial 
information  (Hamilton,  2007).  The  new  IS  would  give  decision  makers  real  time  visibility  of 
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their  assets  and  weapons  system  status,  synchronize  logistics  planning  and  execution  and,  as  a 
result,  reduce  the  cost  of  global  logistics  operations  (Hamilton,  2007). 

The  ECSS  dream,  however,  was  not  to  be  realized  in  its  current  fonn  as  the  program  was 
cancelled  in  2012.  It  was  detennined  that  an  additional  $1  billion  would  be  required  to  realize 
only  a  quarter  of  the  program  objectives.  The  ECSS  program  failed  because  the  USAF  could  not 
overcome  cultural  resistance  among  its  personnel  to  change  business  processes,  lacked  program 
leadership,  did  not  mitigate  identified  risks,  and  did  not  follow  acquisition  best  practices  (Levin 
&  McCain,  2014).  The  program  wasted  eight  years  of  forward  progress  in  transfonning  an 
outdated  supply  chain,  over  $1.1  billion  in  government  funds,  and  left  the  USAF  with  a  similar 
inadequate  logistics  system  ECSS  promised  to  replace  (Levin  &  McCain,  2014). 

The  cancellation  of  the  ECSS  program  left  USAF  supply  chain  stakeholders  with  the 
challenge  of  managing  hundreds  of  inter-connected  and  standalone  infonnation  systems  to 
accomplish  their  mission.  The  USAF  supply  chain  is  managed  by  a  complex  network  of  IS  and 
employs  a  decentralized  approach  to  managing  its  supply  chain  IS.  The  current  supply  chain 
network  is  a  complex  web  of  IS  which  operate  both  independently  and  in  conjunction  with 
others.  To  illustrate  the  complexity  of  the  USAF  supply  chain  IS,  Figure  1  depicts  just  one  of  the 
over  420  IS  interactions  used  to  managed  the  supply  chain.  This  diagram  illustrates  all  the  IS 
systems  which  feed  into  the  Secondary  Item  Requirements  System  (D200A)  and  all  the  IS  to 
which  it  sends  infonnation.  The  other  IS  depicted  in  the  chart  have  similar  information  inflow 
and  outflow  charts.  For  example,  the  D035A  is  one  of  the  systems  which  receives  data  from 
D200A  and  has  50  other  IS  with  which  it  shares  data  (HQ  AFMC/A4RM,  2014). 
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Figure  1:  Example  of  USAF  Supply  Chain  IS  Complexity  (D200  Program  Office,  2013) 
Supply  chain  stakeholders  have  created  IS  specifically  to  enable  their  mission,  which 
may  or  may  not  collaborate  with  other  IS  to  manage  information.  IS  that  do  not  collaborate  with 
other  IS  may  contain  outdated  and  unreliable  information.  The  IS  created  by  the  individual 
stakeholders  are  mission  specific  and  designed  to  optimize  local  objectives  and  missions.  The 
objectives  and  missions  of  stakeholders  often  involve  external  organizations.  The  local  IS 
solutions  do  not  necessarily  account  for  the  objectives  and  mission  of  the  external  users.  The 
local  IS  solution  adds  to  the  number  of  IS  with  which  supply  chain  partners  must  interact.  These 
issues  add  to  the  ineffective  and  inefficient  nature  of  a  decentralized  IS  approach. 


Problem  Statement 

One  of  the  benefits  to  this  approach  is  that  it  would  make  it  difficult  for  adversaries  to 
disrupt  the  supply  chain  by  attacking  an  organization’s  IS.  A  disruption  to  one  system  would  not 
necessarily  impact  the  entire  supply  chain  since  so  many  of  the  IS  work  independently.  Another 
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benefit  is  that  a  stakeholder  can  customize  the  IS  to  satisfy  particular  needs  or  desires.  This 
benefit  can  also  be  a  negative  if  the  stakeholder  does  not  consider  the  needs  of  other  supply  chain 
partners.  The  ability  to  truly  customize  an  IS  to  the  mission  requirements  can  be  a  benefit  if  the 
project  team  develops  an  effective  IS.  A  third  benefit  is  that  a  decentralized  IS  network  is  more 
easily  attained  since  it  delegates  the  responsibility  of  developing  IS  to  stakeholders  and  sub¬ 
organizations.  A  centralized  IS  involving  an  ERP  can  sometimes  be  too  big  for  organizations  to 
develop  and  implement  effectively  at  the  enterprise  level.  The  USAF’s  ECSS  program  is  an 
example  of  a  project  that  failed  because  it  was  too  large  and  complex  in  scope. 

There  are  many  challenges  with  a  decentralized  approach  to  managing  a  supply  chain  IS 
network.  This  report  focuses  on  the  following  problems  which  arise  from  the  decentralized 
approach: 

1 .  Decentralized  IS  management  leads  to  stakeholders  creating  solutions  which  optimize 
local  missions  (hereafter  referred  to  as  “pocket  optimization”). 

2.  Pocket  optimization  results  in  sub-optimal  IS  solution  for  supply  chain  partners. 

3.  Sub-organizations’  lack  of  strategic  outlook,  process  knowledge,  and  resources  lead  to 
an  expensive,  inefficient  and  ineffective  IS  network. 

The  problem  statement  captures  some  of  the  negative  impacts  of  enterprise-level  IS 
deficiencies.  There  are  many  studies  conducted  to  address  the  enterprise  level  issues.  This 
research  addresses  the  problems  created  by  enterprise  level  deficiencies  from  a  supply  chain 
stakeholders’  perspective. 

Purpose 

The  purpose  of  this  study  is  to  address  how  supply  chain  stakeholders  can  mitigate  the 
negative  impacts  of  enterprise-level  IS  deficiencies.  It  does  not  attempt  to  solve  the  enterprise- 
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level  issues  but  focuses  on  how  stakeholders  can  best  adapt  to  the  enterprise’s  current  IS 
environment.  A  decentralized  IS  approach  has  left  it  up  to  sub-organizations  to  develop,  design 
and  implement  IS  which  will  best  enable  their  respective  missions.  Stakeholders  have  to  use 
their  resources  to  develop  an  IS  which  can  neglect  the  larger  organizational  strategy  and  goals. 
This  research  will  assist  managers  challenged  with  enterprise-level  IS  deficiencies  to  develop, 
design  and  implement  an  effective  IS  for  his/her  organization.  The  following  research  and 
investigative  questions  are  used  to  guide  the  research: 

Research  Question: 

How  can  organizations  address  negative  impacts  of  enterprise-level  Information  System 

(IS)  deficiencies? 

Investigative  Questions: 

1.  How  does  an  organization  evaluate  and  identify  the  requirements  of  an  effective 
Infonnation  System  (IS)? 

2.  How  does  an  organization  design  an  IS  which  best  serves  its  intended  function? 

3.  How  does  an  organization  adopt  and  implement  its  IS? 

A  literature  review,  which  can  be  found  in  Chapter  2,  is  used  to  propose  a  framework  for 
evaluating  the  IS  challenges  facing  a  USAF  supply  chain  stakeholder.  A  case  study  method  is 
then  used  to  evaluate  the  framework.  The  research  methodology  and  data  collection  sources  are 
detailed  in  Chapter  3.  The  data  collected  in  the  case  study  are  presented  and  analyzed  in  Chapter 

4.  Lastly,  Chapter  5  contains  recommendations  to  manage  the  stakeholder’s  business  process 
and  IS  more  effectively. 
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Assumptions 


There  were  several  assumptions  which  had  to  be  made  in  perfonning  this  case  study.  The 
first  assumption  is  that  the  USAF  Depot  Source  of  Repair  (DSOR)  process  used  for  our  case 
study  is  representative  of  IS  issues  affecting  the  USAF  supply  chain  This  case  study  does  not 
attempt  to  address  any  non-IS  issues  within  the  USAF  supply  chain. 

An  assumption  made  in  the  framework  developed  from  the  literature  review  is  that  the 
organization  is  able  to  source  the  software  engineering  capability  required  to  create  an  IS.  This 
research  does  not  focus  on  the  technical  aspect  of  software  engineering  but  discusses  the 
functions,  features  and  qualities  an  effective  IS  should  have.  In  order  to  field  the  designed  IS, 
the  organization  must  use  its  internal  software  engineering  capabilities  or  partner  with  a 
contractor  to  design  it  for  them. 

The  last  assumption  made  in  this  case  study  is  that  the  43  NSNs  used  to  compare  the  data 
quality  across  six  IS  is  representative  of  the  DSOR  database.  The  43  NSNs  were  selected  from  a 
diverse  set  of  aircraft  with  varying  missions  and  with  different  demand  levels. 
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II.  Literature  Review 


The  literature  review  addresses  the  underlying  problem  by  addressing  three  topics.  The 
first  topic  is  a  literature  review  in  business  case  design  and  strategic  functions  of  IS  development. 
The  second  topic  is  related  to  the  general  functions,  features  and  qualities  which  are  desirable  in 
IS  design.  The  third  topic  presents  best  practices  for  implementation  and  diffusion  of  IS  in  an 
organization.  The  literature  review  consisted  of  48  academic  sources,  which  contributed  to  a 
framework  presented  at  the  end  of  this  chapter. 

Business  Case  Analysis 

A  literature  review  of  IS,  management  and  other  academic  journals  revealed  there  are 
some  common  approaches  to  establishing  a  business  case  for  an  IS  project.  Most  of  these 
business  case  approaches  involve  strategic  level  planning  and  leadership  involvement.  A  table  of 
sources  and  the  common  themes  found  in  the  literature  review  is  provided  in  Table  1. 


Table  1:  Business  Case  Literature  Review  Findings 


Source 

Gain  leadership  support  at 
appropriate  level 

Business  Process 
Reengineering 

reqmts  /  objectives  (business 
case) 

Evaluate  organization’s 
resource  availability 

Evaluate  organizational 
knowledge  capabilities 

Align  organization  &  IS 
strategies 

Aladwani,  2001 

X 

X 

Bingi,  Sharma,  &  Godla,  2006 

X 

X 

X 

X 

X 

Bostrom  &  Heinen,  1977 

X 

X 

X 

Bostrom  &  Heinen,  1977 

X 

X 

X 

X 

X 

DeLone  &  McLean,  2003 

X 

X 

Dorling,  1993 

X 

X 

X 

X 

Ein-Dor  &  Segev,  1978 

X 

X 

X 

7 


X 


X 


X 


X 


Garg,  Goyal,  &  Lather,  2010 
Ghobakhloo,  Hong,  Sabouri,  &  Zulkifli,  x 

2012 _ 

Hamilton,  2007  x 

Hazen  &  Sankar,  2015 

Holland  &  Light,  1999 _ x 

Jukic,  Jukic,  &  Velasco,  2009 _ 

Kholeif,  Abdel-Kader,  &  Sherer,  2007 _ x 

King,  1978 _ 

King,  2013 _ x 

Kottemann  &  Konsynski,  1984 

Kumar,  Maheshwari,  &  Kumar,  2002  x 

Lambert,  2014 

Lee,  Lee,  &  Lin,  2007 _ 

Levin  &  McCain,  2014  x 

Markus,  1983 _ 

Mohan  &  Ahlemann,  2013 

Nah,  Zuckweiler,  &  Lau,  2003 _ x 

Saeed  &  Abdinnour,  2013 _ 

Saeed  &  Abdinnour-Helm,  2008 _ x 

Schmitt  &  Kozar,  1978  x 

Segars,  1998 _ 

Soh,  Kien,  &  Tay-Yap,  2000 _ 

Subramanian,  Klein,  Jiang,  &  Chan,  2009  x 

Wilkin  &  Cerpa,  2012  x 

Wilkin  &  Davern,  2012 
Williams  &  Beatty,  2006 

Zollar,  1999 _ x 

Zoughbi,  2013 _ 


These  common  findings  were  captured  in  the  sections  below.  They  contribute  to  the 
business  case  development  stage  of  the  conceptual  framework. 

Align  organizational  and  IS  strategies 

The  literature  review  revealed  that  the  alignment  of  the  organization’s  strategic  goal  and 

IS  strategic  goal  is  a  critical  part  of  a  successful  IS  project.  Misalignment  of  these  two  goals  is  a 
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significant  contributor  to  why  over  70%  of  IS  related  projects  fail  (Garg,  Goyal,  &  Lather,  2010). 
Most  IS  projects  that  do  not  contribute  to  the  organization’s  strategic  goals  become  obsolete, 
ineffective  or  lead  to  user  dissatisfaction  (Garg,  Goyal,  &  Lather,  2010). 

A  system  cannot  be  successful  by  its  features  and  functionality  alone;  it  must  contribute 
to  a  strategic  goal  as  detennined  by  the  organization.  Managers  must  refrain  from  the  tendency 
to  develop  IS  in  terms  of  the  cost  savings  but  instead  focus  on  the  business  benefits  that  can  be 
gained  from  the  new  features  and  functions  (Williams  &  Beatty,  2006).  Managers  have  a 
tendency  to  tackle  IS  projects  without  analyzing  the  organization’s  processes  and  how  those 
processes  support  organizational  strategy,  a  misstep  which  leads  to  post  deployment  problems 
(Jukic,  Jukic,  &  Velasco,  2009). 

A  framework  presented  by  William  King  is  a  good  example  of  how  to  effectively  align 
organizational  and  IS  goals.  This  is  a  critical  step  in  the  business  case  development  because  the 
IS  strategy  is  the  first  crucial  step  for  system  development  (King,  1978).  In  his  framework,  King 
takes  into  consideration  all  of  the  organization’s  stakeholders  in  establishing  the  organizational 
strategy  set.  These  stakeholders  include  customers,  stockholders,  government,  lenders, 
employees,  management  and  the  general  public.  The  organizational  strategy  set  is  used  to 
identify  the  IS  strategy  set,  which  include  three  key  components.  The  system  objective 
component  is  the  purpose  which  the  IS  is  to  serve  (e.g.,  “to  permit  the  payment  of  98%  of 
invoices  by  the  due  date”)  (King,  1978).  The  constraint  component  involves  factors  both  internal 
(personnel,  practices,  resources)  and  external  (government,  industry  practices,  inter- 
organizational  collaboration)  which  hinder  the  organization’s  ability  to  carry  out  the  system 
objectives  (King,  1978).  The  strategy  component  helps  guide  the  IS  design  effort.  In  this  step,  it 
is  important  to  decide  how  the  IS  will  be  designed,  by  whom,  using  which  resources  and  within 
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what  timeline.  An  important  decision  factor  at  this  stage  is  detennining  whether  the  organization 
has  the  technological  capability  to  design  and  program  the  IS  organically  or  if  they  must 
outsource  to  a  private  software  development  firm.  Detennining  this  early  on  will  help  with  the 
IS  design  planning  in  the  next  step  of  IS  development.  An  example  of  organizational  and  IS 
strategic  goals  are  provided  in  Appendix  1 . 

Once  the  organizational  strategy  set  has  been  determined,  analysts  familiar  with  the 
available  system  alternatives,  configurations  and  attributes  transform  the  organizational  strategy 
into  IS  strategy  set  (King,  1978).  It  is  important  that  these  analysts  stay  in  constant 
communication  with  management  and  solicit  their  feedback. 

Enlist  support  at  appropriate  level 

An  important  step  early  in  the  project  development  and  strategic  planning  stage  is  to  get 
the  involvement  and  support  of  a  powerful  champion  with  funding  authority  (Schmitt  &  Kozar, 
1978).  Generally,  the  type  of  power  and  authority  necessary  for  the  implementation  of  an  IS 
project  resides  with  the  top  management  of  an  organization. 

The  support  of  top  management  or  someone  with  the  appropriate  authority  and  influence 
is  critical  to  the  development  and  deployment  of  an  IS  project.  Top  management  is  more  likely 
to  link  the  organizational  and  IS  strategies  together  to  get  the  most  out  of  the  organization’s 
investment.  They  are  also  more  readily  able  to  secure  the  funding  required  to  implement  the  IT 
project  (Schmitt  &  Kozar,  1978).  A  leader  in  a  position  of  authority  can  also  direct  the 
involvement  and  cooperation  of  any  sub -organization  to  collaborate  on  the  development  and 
implementation  of  an  IS.  Having  someone  with  this  type  of  authority  can  be  beneficial  to 
developing  a  truly  effective  IS. 
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Having  the  support  of  a  leader  at  the  appropriate  level  also  ensures  there  are  benefits  to 
be  realized  by  all  sub-organizations  involved  in  the  project.  This  is  a  key  aspect  to  addressing 
the  enterprise-level  IS  deficiencies.  In  a  decentralized  IS  network,  organizations  tend  to  develop 
IS  which  help  their  local  mission.  The  issue  is  that  their  mission  involves  other  stakeholders 
which  do  not  realize  the  same  IS  benefits.  If  external  organizations  are  required  to  adopt  an  IS 
which  they  do  not  benefit  from,  they  will  not  be  motivated  to  help  the  IS  be  implemented  and 
used  properly  (Hazen,  2012).  Support  at  the  proper  level  ensures  that  new  IS  innovations  are 
developed  to  truly  benefit  all  the  organizations  involved  and  not  just  one  sub-organization. 

Evaluate  organizational  capabilities 

Any  time  an  organization  is  making  a  large  investment  in  a  project,  it  is  important  to 
evaluate  whether  it  is  able  to  execute  the  project  as  intended.  There  are  multiple  factors  which 
go  into  determining  whether  an  organization  is  able  to  adequately  execute  the  project.  To 
detennine  which  factors  are  critical  to  determining  an  organization’s  IS  capability;  factors  from 
three  existing  theories  are  listed  in  Table  2.  These  combined  factors  are  divided  into  three 
categories;  factors  that  are  within  the  organization’s  control,  factors  that  can  be  partially 
controlled  by  the  organization  and  factors  over  which  the  organization  has  no  control  (Ein-Dor  & 
Segev,  1978). 


Table  2:  Organizational  Factors  in  IS  Adoption 


Factor 

Source 

Uncontrollable  factors 

Organizational  size 

Ein-Dor  &  Segev,  1978 

Organizational  structure 

Ein-Dor  &  Segev,  1978 

Organizational  time  frame 

Ein-Dor  &  Segev,  1978 

Extra-organizational  situation 

Ein-Dor  &  Segev,  1978 

IT  products  in  market 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

External  expertise  &  service 
availability  &  support 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 
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Process  compatibility 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

Partially  controllable  factors 

Firm’s  resources 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

Financial  resource  availability 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

Organization’s  technical  expertise 

Lee,  Lee,  &  Lin,  2007 

Knowledge 

acquisition/  application/  sharing 

Lee,  Lee,  &  Lin,  2007 

CEO’s  support  and  commitment 

Ein-Dor  &  Segev,  1978 

Organizational  maturity 

Ein-Dor  &  Segev,  1978 

Organizational  climate 

Ein-Dor  &  Segev,  1978 

Fully  controllable  factors 

Training  availability 

Lee,  Lee,  &  Lin,  2007 

Steering  committee 

Ein-Dor  &  Segev,  1978 

Users’  participation  and 

involvement 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

Organizational  culture 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

Integration  of  internal  processes 

Ghobakhloo,  Hong,  Sabouri, 
&  Zulkifli,  2012 

Ein-Dor  and  Segev  propose  steps  to  determine  whether  the  uncontrollable  and  partially 
controllable  factors  are  too  significant  to  overcome.  The  first  step  is  to  analyze  the 
uncontrollable  factors  to  determine  if  those  factors  are  hostile  or  can  be  managed.  If  there  are  no 
solutions  to  addressing  the  challenges  posed  by  uncontrollable  factors,  the  program  should  be 
abandoned.  If  there  are  ways  to  address  those  challenges,  even  partially,  then  the  organization 
should  adopt  those  measures.  The  next  step  is  to  analyze  the  partially  controllable  factors  and 
detennine  if  there  can  be  sufficient  changes  made  to  address  the  impact  of  those  factors.  If  there 
are  no  feasible  modifications,  the  project  must  be  abandoned.  If  there  are  possible  modifications, 
then  the  organization  may  move  on  to  initiating  project  development  or  changes  (Ein-Dor  & 
Segev,  1978). 
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Map  Information  Flow 

This  step  is  critical  to  understanding  how  the  IS  must  be  set  up  to  meet  the  business 
process  or  how  the  business  process  must  be  amended  to  align  with  IS  capabilities.  Infonnation 
flow  mapping  is  determining  how  the  infonnation  will  be  transferred  in,  what  the  outputs  are  and 
the  stakeholders  involved  (Lambert,  2014).  The  following  steps  can  be  taken  to  determine  the 
information  flow  within  the  organization  (Lambert,  2014): 

1 .  Detennine  data  requirements 

2.  Detennine  sources  of  data 

3.  Detennine  how  output/infonnation  will  be  shared 

4.  Consider  how  inputs  and  outputs  can  be  used  to  shape  IS  and  organizational  strategy 

The  information  flow  map  must  involve  all  applicable  stakeholders,  both  internal  and 
external  to  the  organization.  One  of  the  most  challenging  factors  will  be  the  use  of  technology 
and  integrating  the  data  flow  with  other  members  of  the  supply  chain  to  facilitate  the  business 
process  (Lambert,  2014).  These  requirements  touch  on  the  topic  of  interoperability,  which  will 
be  discussed  in  the  next  section. 

Mapping  the  infonnation  flow  will  help  identify  the  gap  between  the  organization’s 
information  processing  needs  and  its  capabilities.  One  of  the  goals  in  the  IS  design  must  be  to 
close  the  gap  between  organization’s  information  processing  needs  and  its  capabilities  in  order  to 
successfully  develop  and  implement  an  IS  (Hazen  &  Sankar,  2015). 

Determine  Business  Process  Reengineering  (BPR)  Feasibility 

Multiple  sources  discussed  the  importance  of  configuring  the  business  process  with  the 
software  used  as  a  support  tool  for  executing  the  process.  The  IS  being  evaluated  needs  to  be 
properly  aligned  with  the  process  in  which  the  organization  executes  its  tasks  and  objectives 
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(Holland  &  Light,  1999).  For  example,  once  the  customer  places  an  order  with  the  cashier  at  a 
fast  food  restaurant,  the  order  needs  to  be  relayed  to  the  cook.  The  IS  should  be  aligned  with  this 
process  such  that  the  cashier  inputs  the  order  and  the  information  is  transmitted  to  the  cook.  The 
process  of  aligning  the  software  functions  and  the  business  process  is  called  business  process 
reengineering  (BPR).  This  process  is  summarized  in  a  4-step  model  in  Figure  2. 


<  > 

Understand  the 
current  processes 
(referred  to  “As-is” 
process). 

V  J 


f  Develop  new  > 

processes  (referred 
to  as  “To-be” 
process)  using 
input  from  key 
V  stakeholders  j 


( - \ 

Modify  or  design 
IS  to  support  new 
process 

v _ _ / 


/  \ 

Integrate  new 
process  into  the 
organization  using 
diffusion  methods 

V _ / 


Figure  2:  Model  for  BPR  (Levin  &  McCain,  2014) 

Most  of  the  research  found  in  the  literature  review  recommends  the  BPR  step  be  analyzed 
in  the  software  development  stage.  Understanding  the  feasibility  of  the  necessary  Business 
Process  Reengineering  at  an  earlier  stage  will  improve  the  IS  project  outcomes  (Levin  & 

McCain,  2014).  The  decision  makers  can  detennine  early  on  whether  the  organization  will  be 
capable  of  aligning  its  process  and  software  to  attain  the  desired  objectives  of  the  project.  It  will 
save  a  significant  investment  in  time  and  money  if  the  organization  is  unable  to  reengineer  its 
processes  and  software  (Levin  &  McCain,  2014). 

IS  Design  Evaluation 

A  content  analysis  in  the  literature  review  revealed  some  common  approaches  to  IS 
design.  There  are  certain  functions  and  capabilities  that  are  critical  to  the  successful 
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development  and  implementation  of  any  IS.  Most  of  these  recommendations  are  categorized 
under  the  umbrella  of  “software  engineering  practices”.  A  table  of  sources  and  the  themes  found 
in  the  literature  review  can  be  found  in  Table  3. 

Table  3:  IS  Design  Content  Analysis 
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X 


X 


X 


X 


Kottemann  &  Konsynski, 

1984 _ _ 

Kumar,  Maheshwari,  & 

Kumar,  2002 

Lambert,  2014 
Lane,  2009 
Lee,  Lee,  &  Lin,  2007 
Markus,  1983  I  x  I  x  I  x  I  x  I  |x|  lx 


Marques  dos  Santos  & 

Reinhard,  2012 

Mohan  &  Ahlemann,  2013  x  x  x 

Nah,  Zuckweiler,  &  Lau,  2003  x  x 

Saeed  &  Abdinnour,  2013  x  x  x 


Saeed  &  Abdinnour-Helm, 

2008  x  x  x  x 


Schmitt  &  Kozar,  1978 
Segars,  1998 

Soh,  Kien,  &  Tay-Yap,  2000 

Subramanian,  Klein,  Jiang,  & 
Chan,  2009 

Wilkin  &  Cerpa,  2012 
Wilkin  &  Davern,  2012 
Williams  &  Beatty,  2006 

Xue,  Zhang,  Ling,  &  Zhao, 
2013 

Zollar,  1999 


Adopt  good  project  management  practices 

Successful  IS  projects  need  “managers  to  develop  project  management  practices  that  are 
successful  in  a  global,  integrated  and  highly  distributed  computing  environment  (Garg,  Goyal,  & 
Lather,  2010:  278).”  It  is  important  for  managers  to  maintain  roles  and  responsibilities,  and 
avoid  scope  deviations,  schedule  slippage,  and  cost  overruns  but  they  must  ensure  these 
requirements  do  not  hinder  capturing  the  organization’s  best  practices  from  lessons  learned  in 
previous  projects  (Subramanian,  Klein,  Jiang,  &  Chan,  2009). 
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Figure  3  visually  depicts  recommended  IS  project  management  practices  found  in  the 
literature  review.  Good  project  management  practices  can  be  summarized  in  4  steps;  structure 
the  project,  set  objectives  (milestones),  gain  commitment,  and  manage  the  project  (McManus, 
2014).  The  project  must  have  a  strong  project  manager  with  process  knowledge  and  commercial 
skills.  He/she  needs  to  fonn  a  high  performing  implementation  team  and  employ  proven 
procedures  and  practices.  Any  tool(s)  used  in  managing  a  project  must  easily  populate 


information,  and  provide  accurate,  complete  and  timely  data  for  effective  decision  making. 


Figure  3:  Model  for  IS  Project  Management  Practices  (McManus,  2014) 

Software  Design,  function  or  quality 

Most  of  the  findings  in  the  IS  design  content  analysis  may  be  categorized  under  the  title 
“software  design,  function  or  quality.”  Sub-organizations  must  focus  on  achieving  these 
outcomes  in  their  IS  design.  These  features,  functions,  and  qualities  are  critical  to  the  successful 
diffusion  of  the  IS  because  it  impacts  the  functionality  and  the  perceived  usefulness  to  the  user. 
The  software  design  functions,  features  and  qualities  are  summarized  in  Table  4. 
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Table  4:  Software  Design  Function,  Feature  and  Quality  Best  Practices 


Software  Design  Function, 
Feature,  or  Quality 

Source 

Data  Quality 

Lane,  2009 

Interoperability 

Chalyvidis,  Ogden,  &  Johnson,  2013 

Systems  Quality 

DeLone  &  McLean,  2003 

End  user  requirements 

DeLone  &  McLean,  2003 

Data  Quality.  Any  data  contained  within  an  IS  must  be  accurate  and  reliable. 

This  means  it  needs  to  be  from  a  trusted  source,  up  to  date  and  correct.  The  data  residing  within 
an  IS  must  be  complete,  easy  to  understand,  personalized,  relevant,  and  secure  (DeLone  & 
McLean,  2003).  It  is  critical  to  any  successful  IS  implementation  as  “it  enhances  system 
performance,  builds  trust  in  the  system  among  users,  and  provides  leadership  with  accurate 
infonnation  for  better  decision  making  (Lane,  2009:  56).” 

Interoperability.  It  is  critical  for  any  organization  which  is  part  of  a  supply  chain 
to  embrace  the  concept  of  collaboration.  Collaboration  among  stakeholders  allow  the  supply 
chain  to  make  changes  in  its  decision  making  process  and  take  actions  which  are  beneficial  to  the 
overall  supply  chain  (Chalyvidis,  Ogden,  &  Johnson,  2013).  In  terms  of  IS,  interoperability  is  the 
ability  of  two  or  more  systems  or  elements  to  exchange  infonnation  among  them  and  to  use  the 
infonnation  that  was  exchanged  (Marques  dos  Santos  &  Reinhard,  2012).  It  identifies  the 
capacity  of  individual  units  to  work  together  to  accomplish  useful  functions.  Some  of  the 
benefits  of  making  an  IS  interoperable  with  other  IS  are  increased  effectiveness,  efficiency,  and 
responsiveness  (Marques  dos  Santos  &  Reinhard,  2012). 
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System  Quality.  System  quality  refers  to  the  usability,  availability,  reliability, 
adaptability,  and  response  time  (e.g.,  download  time)  of  an  IS  (DeLone  &  McLean,  2003).  The 
commonality  among  these  traits  is  that  they  add  value  to  the  user  and  impacts  the  user’s 
perception  of  the  IS  usefulness.  This  means  the  software  used  to  create  the  IS  must  be  on  equal 
footing  with  the  latest  technology  in  order  for  it  to  be  compatible  with  other  systems  (DeLone  & 
McLean,  2003).  Quality  software  enhances  the  user  experience  through  its  friendly  interface  and 
reliability.  Users  should  not  have  to  struggle  to  comprehend  the  simplest  tasks  or  wait  an 
extended  amount  of  time  for  the  program  to  load. 

End-user  requirement.  The  IS  must  deliver  what  the  end  user  needs.  This 
includes  customer  support  and  social  system  goals.  The  customer  support  aspect  of  this 
requirement  refers  to  the  overall  support  delivered  to  the  user  by  the  organization.  This  service 
can  be  delivered  by  the  IS  department,  a  new  organizational  unit,  or  outside  contractor. 

Providing  adequate  customer  support  is  extremely  important  since  the  users  are  now  our 
customers.  Poor  user  support  will  translate  into  low  usage  or  IS  failure  (DeLone  &  McLean, 
2003).  The  socio-technical  theory  attempts  to  increase  usage  rates  and  IS  usefulness  by 
increasing  amount  of  feedback  received,  facilitate  intra-organizational  communication,  and  give 
more  control  to  end  users  to  help  them  take  ownership  of  the  tasks  (Bostrom  &  Heinen,  1977).  It 
also  helps  users  actively  engage  in  providing  feedback  and  finding  new  and  innovative  uses. 

These  software  development  functions,  features  and  qualities  are  critical  in  detennining 
how  useful  the  IS  will  be  to  the  organization.  These  functions  take  into  factor  both  technical  and 
social  aspects  of  technology  development.  The  usefulness  of  the  IS  is  directly  related  to  it  being 
used  as  intended.  If  the  organization  aligns  its  organizational  goals  with  IS  goals,  then  the 
intended  use  of  the  IS  will  help  it  achieve  its  organizational  goals  (DeLone  &  McLean,  2003). 
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The  relationship  between  software  design  functions,  features  and  qualities  and  the  IS  strategy 
execution  is  summarized  in  Figure  4. 


Figure  4:  IS  Design  Functions,  Features,  &  Qualities 


Diffusion 

The  successful  implementation  of  an  IS  is  directly  related  to  how  well  it  is  tied  to  the 
organization’s  strategy  and  design,  both  of  which  are  explained  in  detail  in  the  previous  two 
stages  (Hazen,  Overstreet,  &  Cegielski,  2012).  Once  the  IS  strategy  has  been  determined  in  the 
business  case  development  stage  and  the  IS  is  designed  using  the  proposed  model,  there  are  post¬ 
adoption  (referred  to  as  “diffusion”)  steps  that  must  be  taken  to  ensure  the  IS  is  effectively 
diffused  within  the  organization. 

A  content  analysis  of  the  literature  review  revealed  several  common  theories  and  findings 
in  existing  research.  A  list  of  sources  for  the  diffusion  literature  review  is  provided  in  Table  5. 
These  findings  are  the  basis  for  the  diffusion  part  of  our  conceptual  framework  and  are  explained 
in  greater  detail  in  the  following  sections. 
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Table  5:  Diffusion  Content  Analysis 


Source _ 

Kumar,  Maheshwari,  &  Kumar,  2002 

Aladwani,  2001 
Bingi,  Sharma,  &  Godla,  2006 
Bostrom  &  Heinen,  1977 
Dorling,  1993 

Garg,  Goyal,  &  Lather,  2010 

Ghobakhloo,  Hong,  Sabouri,  &  Zulkifli, 

2012 _ 

Hamilton,  2007 

Hazen  &  Sankar,  2015 

Hazen,  Hanna,  &  Hall,  2014 

Hazen,  Overstreet,  &  Cegielski,  2012 

Holland  &  Light,  1999 

Kholeif,  Abdel-Kader,  &  Sherer,  2007 

King,  1978 

King,  2013 

Lee,  Lee,  &  Lin,  2007 

Levin  &  McCain,  2014 

Markus,  1983 

Mohan  &  Ahlemann,  2013 

Nah,  Zuckweiler,  &  Lau,  2003 

Saeed  &  Abdinnour,  2013 

Saeed  &  Abdinnour-Helm,  2008 

Schmitt  &  Kozar,  1978 

Subramanian,  Klein,  Jiang,  &  Chan,  2009 

Wilkin  &  Cerpa,  2012 

Wilkin  &  Davem,  2012 
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Establish  Fonnal  Guidance 


Zollar,  1999 

X 

X 

Zoughbi,  2013 

X 

Influential  leadership  support 

This  leadership  support  is  different  than  the  leadership  support  in  the  case  development 
stage  because  it  requires  day-to-day  involvement.  In  the  case  development  stage,  support  from 
top  management  is  required  to  get  the  project  started.  In  this  situation,  the  project  requires 
someone  who  has  enough  influence  in  the  organization  but  can  also  play  a  large  role  in  the 
implementation  of  the  project.  The  influential  leader  should  be  someone  who  can  allocate  and 
manage  financial  resources  and  has  the  power  to  gather  support  for  the  project  (Zollar,  1999). 

Ideally,  this  would  be  the  project  manager  but  it  can  be  rare  to  find  a  project  manager 
with  so  much  power  or  influence.  An  influential  manager  is  crucial  in  addressing  user  concerns 
and  overcoming  any  resistance  early  in  the  diffusion  stage  (King,  2013).  Simply  communicating 
with  users  how  the  implemented  IS  will  work  and  informing  users  of  its  benefits  go  a  long  way 
in  addressing  user  concerns  and  getting  their  buy-in  (Aladwani,  2001).  The  project  leaders  must 
be  the  biggest  advocate  for  the  IS  and  have  good  project  management  skills  and  tools  to  field  an 
effective  IS. 

Establish  Formal  Guidance 

This  step  refers  to  the  “degree  to  which  formal  regulations  and  governing  ordinance  are 
established  and  updated  to  account  for  the  innovation  (Hazen,  Overstreet,  &  Cegielski,  2012: 
126).”  After  the  IS  is  developed  and  ready  to  be  implemented,  the  organization  must  fonnalize 
the  IS  by  establishing  official  guidance  which  dictates  its  use,  capability  and/or  requirements. 
This  guidance  can  come  in  the  form  of  user  manuals,  instructional  guidance,  process  integration, 
or  other  official  channels  (Hazen,  Overstreet,  &  Cegielski,  2012).  This  guidance  validates  the 
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importance  of  the  IS  to  the  organization  and  provides  users  with  instructions  for  how  the  IS  must 
be  utilized. 

Provide  adequate  training  /  user  support 

This  step  refers  to  the  “degree  to  which  the  organization  offers  opportunities  for  initial 
and/or  recurring  training  regarding  the  innovation  (Hazen,  Overstreet,  &  Cegielski,  2012:  126).” 
In  a  study  of  820  IS  executives,  the  availability  of  training  was  found  to  be  positively  associated 
with  the  successful  implementation  of  IS  (Lee,  Lee,  &  Lin,  2007).  Training  users  to  use  the  IS  is 
directly  related  to  how  successfully  the  IS  will  be  incorporated  (Hazen,  Hanna,  &  Hall,  2014). 
Training  must  be  effective  enough  for  users  to  use  and  understand  the  IS  effectively  and 
accomplish  their  role  in  the  business  process.  The  cross-functional  project  team  should  be 
afforded  an  opportunity  to  develop  the  training  plan  as  it  will  be  able  to  provide  input  from  the 
perspective  of  each  stakeholder. 

Implement  Continuous  Improvement  / Feedback  Methods 

Once  the  system  is  designed  and  implemented,  it  must  be  monitored  to  ensure  it  is 
effectively  meeting  its  goals  (Bostrom  &  Heinen,  1977).  If  the  IS  goals  are  not  being  met, 
changes  must  be  made.  Continuous  improvement  is  an  iterative  process  which  must  take  into 
account  user  feedback.  User  feedback  is  crucial  in  being  able  to  make  adjustments  on  the  basis 
of  socio-technical  theory,  which  focuses  on  the  user’s  perception  of  the  IS  (Bostrom  &  Heinen, 
1977).  The  continuous  improvement  efforts  will  be  made  more  effective  with  input  from  users, 
which  is  why  implementing  an  effective  user  feedback  method  is  crucial. 

Framework 

The  literature  review  is  intended  to  identify  existing  research  and  theories  on  IS  strategy, 
design  and  diffusion.  Its  purpose  is  to  offer  a  solution  to  minimizing  the  challenge  of  working  in 
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an  enterprise  which  employs  a  decentralized  IS  approach.  The  findings  in  the  literature  review 
can  be  summarized  in  the  model  developed  in  Figure  5. 


1 .  Business  Case 
Development 
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(Bostroni  &  Heinen,  1977) 


Figure  5:  IS  Development  Framework 
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III.  Methodology 


This  section  of  the  report  introduces  the  case  study  subject,  the  data  collection  methods 
used  in  the  case  study,  and  the  various  sources  of  infonnation  reviewed.  The  case  study  subject 
for  the  current  study  is  the  Depot  Source  of  Repair  (DSOR)  team.  It  is  part  of  the  Logistics 
Directorate  (A4)  of  the  Air  Force  Materiel  Command  (AFMC)  Headquarters  staff.  The  study 
took  place  between  January  2014  and  January  2015.  The  data  collection  methods  and  sources  of 
information  are  detailed  in  this  chapter.  The  following  section  introduces  the  DSOR  team  and  its 
role  within  the  Department  of  Defense  and  the  USAF. 

Case  Study  Subject 

The  Department  of  Defense  (DoD)  has  a  process  for  developing  and  acquiring  weapons 

and  other  systems  called  the  Defense  Acquisition  System.  It  is  divided  into  three  milestones 

(MS).  MS  A  initiates  technology  maturation  and  risk  reduction,  MS  B  focuses  on  engineering 

and  manufacturing  development  and  MS  C  executes  production  and  deployment  of  the  weapon 

system  (Schwartz,  2014).  The  Initial  Operating  Capability  (IOC)  is  attained  when  a  sufficient 

amount  of  systems  are  delivered  to  the  USAF  to  begin  operations  and  Full  Operational 

Capability  (FOC)  is  achieved  when  the  system  has  reached  complete  operational  capability 

(Schwartz,  2014).  The  USAF  uses  the  DoD  acquisition  process  in  its  acquisition  of  weapon 

systems.  Any  reference  to  the  DoD  Acquisition  process  will  be  made  using  the  tenn  “USAF 

acquisition  process”.  It  is  important  to  make  this  distinction  because  the  DSOR  team  executes  its 

mission  for  the  USAF  alone.  A  visual  depiction  of  the  entire  USAF  Acquisition  System  is 

shown  in  Appendix  2  to  show  its  complexity  (Defense  Acquisition  Unversity,  2010).  A 

simplified  process  map  of  the  USAF  acquisition  process  and  how  the  DSOR  process  fits  within  it 

is  provided  in  Figure  6.  The  DSOR  process  executed  by  the  DSOR  team  is  one  of  many  sub- 
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processes  of  the  USAF  acquisition  system.  This  case  study  does  not  focus  in  depth  on  the  entire 
acquisition  process  but  on  the  DSOR  team’s  involvement  within  it. 


DSOR 

Team 

Involvement: 


Acquisition 

Stage: 


USAF 


Project 

Milestone: 


Figure  6:  USAF  Acquisition  Process  (AFMC/A4DC,  2014) 


The  DSOR  team  manages  a  process  in  which  the  USAF  postures  its  depot  level 
maintenance  workloads  (AF/AQXA,  2013).  Depot  maintenance  is  defined  as  “. .  .any  action 
performed  on  materiel  or  software  in  the  conduct  of  inspection,  repair,  overhaul,  or  the 
modification  or  rebuild  of  end-items,  assemblies,  subassemblies  and  parts...  (AFMC/A4DC, 
2014:  21).”  Any  hardware,  software,  new  acquisitions,  and  fielded  systems  managed  by  the 
USAF  or  its  private  contractor  are  required  to  have  an  organic  or  contracted  depot  maintenance 
capability.  The  DSOR  process  is  in  place  to  identify  the  depot  or  contract  where  the  repair 
capability  needs  to  be  established  (AF/AQXA,  2013). 

The  DSOR  team  works  with  similar  sub-organizations  in  the  Navy,  Army  and  Marine 
Corp  to  identify  the  best  source  of  repair  for  its  systems  and  subsystems.  Together,  these  sub¬ 
organizations  determine  how  to  best  use  the  repair  capabilities  and  resources  in  all  of  the  DoD. 
The  DoD  was  budgeted  to  spend  nearly  $30  billion  on  its  military  repair  program  in  2014.  A 
breakdown  of  the  fiscal  year  2014  (FY14)  budget  by  each  branch  is  depicted  in  Figure  7  (Office 
of  the  Secretary  of  Defense,  2013). 
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FY14  DoD  Depot  Repair  Budget 
(in  millions) 


Air  Force, 
$12,825.7, 
43% 


Army, 

$5,263.6 , 17% 

Marines, 
$785.8 , 3% 


Navy, 

$11,061.5, 

37% 


Figure  7:  DoD  FY14  Projected  Depot  Repair  Budget 


The  DSOR  team  is  in  charge  of  posturing  USAF  repair  capabilities  across  its  organic 
repair  depots  or  private  industry  partners  (via  contract).  It  is  also  the  organization  with  primary 
responsibility  for  depot  maintenance  activation  policy  (AF/AQXA,  2013).  This  team  plays  a 
critical  role  in  managing  and  executing  the  USAF’s  nearly  $13  billion  depot  repair  program.  The 
repair  capabilities  are  categorized  into  functional  entities  to  accomplish  depot  level  maintenance 
on  a  specific  group  of  items  called  Technology  Repair  Centers  (TRC).  There  are  24  TRCs  in  the 
USAF  which  reside  within  three  USAF  depots  (hereafter  referred  to  as  Air  Logistics  Complex 
(ALC)):  Oklahoma  City  ALC  in  Oklahoma,  Ogden  ALC  in  Utah,  and  Warner  Robins  ALC  in 
Georgia  (AFMC/A4DC,  2014).  A  breakdown  of  each  TRC  and  the  depot  in  which  that  function 
is  maintained  is  listed  in  Appendix  3. 
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The  DSOR  team  is  divided  into  four  sections;  Source  of  Repair  Analysis  (SORA)  team, 
CORE  and  Candidate  Depot  (CCD)  team,  the  Depot  Maintenance  Inter-service  (DMI)  team  and 
the  Depot  Activation  Cell  (DAC). 

The  DSOR  team’s  primary  function  is  approving  the  depot  in  which  weapons  systems 
and  subsystems  may  be  repaired.  This  process  begins  with  the  Program  Manager  (PM) 
submitting  an  approval  request  to  the  SORA  section.  The  SORA  section  validates  the 
information  and  begins  coordination  with  the  CCD  section.  The  CCD  section  helps  identify  and 
validate  the  candidate  depot  for  the  DSOR  request  and  determines  whether  the  request  is  in 
compliance  with  congressional  regulations  specific  to  military  maintenance.  The  DSOR  request 
is  then  moved  to  the  DMI  section  to  obtain  concurrence  on  the  candidate  depot  from  other 
services.  The  DSOR  request  is  then  approved  by  the  AFMC/A4  Director  and  returned  to  the  PM 
to  continue  the  acquisition  process.  The  DAC  continues  to  work  with  PMs  to  provide  support  in 
case  the  requirements  change  and  the  candidate  depot  needs  to  be  re-evaluated.  The  DAC  also 
performs  3-year  reviews  on  approved  DSOR  requests  to  ensure  the  requirements  have  not 
changed  and  the  maintenance  is  being  conducted  at  the  appropriate  depot  or  with  the  correct 
contract. 

The  DSOR  team  uses  the  DSOR  II  IS  as  a  database,  reports,  and  workflow  process  tool  to 
accomplish  its  mission.  It  is  a  standalone  system  and  does  not  automatically  share  or  update 
infonnation  with  any  other  IS  or  database.  All  infonnation  contained  within  DSOR  II  is  created 
and  maintained  by  its  users.  Its  primary  users  are  members  of  the  AFMC/A4  DSOR  team  and 
PMs  who  need  a  DSOR  request  approved  or  validated  during  a  3-year  periodic  review. 


28 


This  research  was  conducted  using  a  case  study  approach.  This  chapter  details  why  the 
case  study  approach  was  the  best  research  method  for  the  problem  being  addressed  and  the  steps 
that  were  taken  to  conduct  the  research. 

A  case  study  is  used  to  conduct  an  investigation  into  a  real-world  issue  whose  boundaries 
may  not  be  easily  identified  (Yin,  2009).  The  problem  to  be  investigated  may  have  more 
variables  than  quantitative  data  points  and  those  variables  may  come  from  multiple  sources  of 
evidence  (Yin,  2009).  In  a  case  study,  previously  conducted  research  and  developed  theory  may 
be  used  to  guide  data  collection  and  analysis. 

The  case  study  method  is  the  most  appropriate  research  method  for  the  underlying 
problem  identified  in  Chapter  1 .  There  are  existing  theories  and  research  available  to  address  the 
underlying  problem.  Those  existing  theories  were  used  to  evaluate  the  data  collected  from  the 
case  study.  The  case  study  was  conducted  using  a  research  model  presented  in  Yin  (2009)  and  is 
detailed  in  the  sections  below. 

Plan 

The  first  steps  in  conducting  a  case  study  are  to  identify  the  problem  being  investigated 
and  detennine  if  a  case  study  is  the  appropriate  research  method  (Yin,  2009).  The  research 
problem  and  underlying  decision  is  detailed  in  Chapter  1 .  The  issue  requires  a  qualitative 
approach  to  research,  eliminating  the  quantitative  methods  as  options.  There  are  no  quantitative 
methods  of  addressing  enterprise  level  IS  deficiencies  as  it  is  a  management,  policy,  and 
leadership  issue. 

There  are  numerous  qualitative  research  methods  that  were  considered  but  the  case  study 
was  the  ideal  option.  The  ethnography  method  was  not  appropriate  because  the  research  was  not 
addressing  a  cultural  issue  in  which  we  had  to  observe  a  person,  program  or  event  in  their/its 
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natural  setting  (Leedy  &  Ormrod,  2010).  The  phenomenological  study  was  also  not  the  optimal 
option  as  the  research  problem  did  not  call  for  an  investigation  into  people’s  perceptions, 
perspectives  and  understandings  of  a  particular  situation  (Leedy  &  Onnrod,  2010).  The 
grounded  theory  is  not  appropriate  for  this  study  because  the  data  collected  in  this  study  will  not 
be  used  to  develop  a  theory  but  make  managerial  implications  based  on  the  findings  (Leedy  & 
Onnrod,  2010).  Lastly,  the  content  analysis  approach  was  inappropriate  for  this  study  because 
the  research  does  not  require  identification  of  patterns  (Leedy  &  Ormrod,  2010),  only  an  analysis 
of  the  current  application  of  the  IS  compared  to  recommended  practices  found  in  the  literature 
review.  Content  analysis,  however,  was  used  in  the  literature  review  section  to  identify  common 
patterns  in  the  existing  research,  which  help  address  the  research  and  investigative  questions  of 
the  case  study. 

The  case  study  approach  is  the  correct  research  methodology  for  the  problem  being 
investigated  because  the  problem  addresses  how  the  technical,  organizational  and  managerial 
processes  of  the  IS  can  be  improved.  While  it  may  be  the  optimal  method,  there  are  limitations 
of  using  a  case  study.  The  biggest  limitation  is  that  a  case  study  has  the  potential  of  being 
subjective.  The  data  collected  in  a  case  study  can  be  interpreted  in  multiple  ways  and  may  lead 
to  poor  analysis  and  conclusion.  Another  limitation  of  a  case  study  is  that  the  quality  of  the  data 
relies  on  the  knowledge  and  skills  of  the  investigator(s).  If  an  investigator  has  poor  interviewing 
skills,  the  data  collected  from  his/her  interviews  will  be  incomplete  or  contain  poor  information. 

Design 

The  design  stage  of  a  case  study  requires  defining  the  study’s  unit  of  analysis.  In  this 
case  study,  the  DSOR II  IS  is  the  unit  of  analysis.  In  order  to  address  the  underlying  problem, 
the  focal  point  for  the  research  must  be  the  IS  being  used  by  the  case  study  organization.  Using 
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the  DSOR  II  as  a  focal  point,  the  research  will  address  other  strategic  and  organizational  issues 
that  are  involved  in  effectively  managing  DSOR  II. 

The  case  study  question  began  as  “how  does  the  DSOR  team  address  data  discrepancies 
within  its  DSOR  II  IS?”  After  investigating  the  underlying  issue  to  the  DSOR  team’s  challenges, 
the  study  proposition  became  “how  does  an  organization  design  an  effective  IS  in  the  absence  of 
an  effective  enterprise-level  IS?”  The  underlying  problem  is  discussed  in  Chapter  1,  where  the 
research  and  investigative  questions  are  listed.  The  study  proposition  is  the  basis  of  our  literature 
review,  which  can  be  found  in  Chapter  2.  The  literature  review  is  used  to  develop  a  framework 
for  how  an  organization  can  address  enterprise  level  information  system  deficiencies  based  on 
findings  from  existing  research. 

Another  aspect  of  the  design  stage  is  selecting  the  type  of  case  study  that  is  to  be 
conducted.  A  single  case  study  design  was  selected  for  this  research  because  of  the  theoretical 
framework  used  to  evaluate  the  identified  phenomenon.  The  literature  review  developed  a 
conceptual  framework,  which  is  used  to  evaluate  the  DSOR  II  program.  The  framework  was 
developed  with  a  thorough  content  analysis  of  48  academic  sources.  It  combines  sound  methods 
for  developing  an  IS  business  case,  IS  design  factors,  and  diffusion.  This  case  study  tests  a  well- 
formulated  theoretical  framework.  The  use  of  a  well-formulated  theoretical  framework  is  an 
acceptable  rationale  for  a  single  case  study  (Yin,  2009). 

Prepare 

Once  the  case  study  approach  is  selected  and  the  research  and  investigative  questions  are 
identified,  the  next  stage  is  to  prepare  to  conduct  the  case  study.  It  was  important  to  gain 
approval  for  human  subjects  test  since  the  case  study  collection  method  includes  interviews.  It  is 
also  important  to  develop  case  study  protocol  and  identify  data  collection  procedures 
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Human  subjects  interview  requirements 

This  case  study  includes  interviews  with  various  stakeholders  in  the  DSOR  process.  The 
interviewer,  Capt  Dipta  Kazi,  conducted  basic  human  subject  research  training  designed  by  the 
Collaborative  Institutional  Training  Initiative  (CITI).  This  training  included  ethical  testing 
concepts,  including  informed  consent,  privacy  and  confidentiality,  vulnerable  subjects,  conflicts 
of  interest  and  more. 

This  research  qualified  for  an  exemption  from  human  experimentation  requirements 
because  of  the  methods  in  place  to  safeguard  any  identifiable  infonnation  that  may  have  negative 
impacts  to  the  subjects.  The  approved  exemption  memorandum  is  provided  in  Appendix  4. 

.  This  measure  is  in  place  to  safeguard  the  interview  subjects  from  any  negative  repercussions  for 
the  unclassified  infonnation  he/she  contributed  to  the  research.  Any  personally  identifiable 
information  will  be  hidden  in  this  report.  The  interview  documents  will  be  kept  separate  and 
accessible  only  to  the  investigators;  Capt  Dipta  Kazi,  Lt  Col  Matthew  Douglas  and  Dr.  Alan 
Johnson.  The  interview  subjects  are  also  required  to  sign  a  consent  fonn  detailing  the  interview 
procedures  and  risks.  A  sample  consent  form  is  provided  in  Appendix  5. 

Interview  methods 

It  is  also  important  to  identify  the  data  collection  procedures  in  the  preparation  stage. 

The  interview  subjects  were  detennined  based  on  their  role  in  the  DSOR  process.  The  key 
stakeholders  were  identified  in  meetings  and  discussions  with  the  DSOR  team  members. 
Stakeholders  outside  of  the  DSOR  team  include  item  managers,  program  managers,  members  at 
the  depot,  and  IS  experts  involved  in  the  DSOR  process.  The  method  of  reaching  the  interview 
subjects  was  limited  by  time,  ability  to  travel  and  funds.  Subjects  co-located  with  the  research 
team  at  Wright  Patterson  Air  Force  Base  (WPAFB),  Dayton,  Ohio  were  preferred  because  they 
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could  be  met  with  in-person.  If  the  interview  subject  was  not  located  at  WPAFB,  the  interview 
was  conducted  via  telephone  or  electronic  mail  (e-mail). 

Access  to  interview  subjects 

Gaining  access  to  the  interview  subjects  was  a  challenge  which  needed  to  be  addressed. 
We  began  by  soliciting  interviews  from  subjects  who  had  established  professional  relationships 
with  the  DSOR  team.  The  second  approach  was  to  identify  stakeholders  from  the  Enterprise 
Solutions  -  Supply  (ES-S)  IS  database  and  solicit  their  participation  via  email  and  phone  calls. 
Each  of  the  interview  subjects  were  provided  the  consent  form  and  a  summary  sheet  to  give  them 
more  detail  of  the  research  being  conducted.  The  summary  sheet  is  provided  in  Appendix  6. 

The  response  rate  from  the  subjects  was  satisfactory. 

Interview  questions 

The  next  step  in  the  preparation  stage  is  creating  a  set  of  questions  to  guide  the  discussion 
during  the  interviews.  These  questions  were  used  as  a  starting  point  of  the  discussions  and 
follow  on  questions  were  asked  based  on  the  subjects’  response.  The  questions  varied  slightly 
based  on  the  stakeholder  but  were  similar  for  each  of  the  interviews.  Interview  subjects  were 
informed  that  the  objectives  of  the  interview  were  to  understand  the  process  of  working  with 
other  DoD  stakeholders  in  managing  depot  source  of  repair  information  for  USAF  assets  and 
leam  about  the  IS/software  the  interview  subject  used  to  manage  USAF  assets.  Sample  interview 
questions  can  be  found  in  Appendix  7. 

Data  evaluation 

The  information  gathered  from  the  interview  subjects  was  used  primarily  to  verify 
infonnation  already  gathered  from  other  sources  or  gain  new  infonnation  which  can  be  verified 
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by  other  sources.  This  is  important  in  establishing  the  validity  of  the  data  collection  method. 
Infonnation  should  be  verified  by  more  than  one  source  in  order  to  reach  a  reliable  conclusion. 

Resources 

The  DSOR  team  at  HQ  AFMC  provided  the  research  team  with  resources  necessary  to 
conduct  the  study  case.  The  most  important  resource  provided  was  open  access  to  discuss  the 
case  and  request  data  from  the  DSOR  team.  The  researcher  was  set  up  with  a  work  station  co¬ 
located  with  the  DSOR  team,  along  with  a  laptop  computer  and  monitors.  Researchers  were  also 
given  access  to  the  DSOR  II  IS  system  and  provided  assistance  with  gaining  access  to  other 
USAF  IS  pertinent  to  the  study.  The  DSOR  team  provided  all  the  support  and  resources 
necessary  to  execute  the  case  study  design  and  objective. 

Collect 

Multiple  sources  of  evidence  were  used  to  collect  data  for  the  case  study.  The  data  was 
recorded  in  a  case  study  database  and  multiple  chains  of  evidence  used  to  verify  findings.  The 
sources  of  evidence  used  included  documents,  archival  records,  interviews,  direct  observation, 
and  physical  artifacts. 

Documents 

The  case  study  research  data  included  memoranda,  email  correspondence,  individual 
information  databases,  meeting  minutes,  reports,  internal  records,  and  contract  documents. 

These  documents  were  collected  from  the  DSOR  teamwork  files,  the  various  stakeholders 
involved  and  open  sources  available  through  the  Air  Force  Portal.  A  list  of  documents  collected 
and  used  for  analysis  in  the  case  study  is  provided  in  Table  6. 
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Table  6:  List  of  Documents  Reviewed 


Name  of  Document 

1  -  DSOR II  Contract  (Perfonnance  Work  Statement) 

2  -  AFMC  Workload  Distribution  (50/50)  Reporting  Process  101  (Slide  presentation) 

3  -  Office  of  Secretary  of  Defense  Report  on  DoD  Military  Maintenance  Budget 

4  -  Technology  Repair  Center  (TRC)  101  Review  (Presentation  slides) 

5  -  DoD  Depot  Maintenance  Map 

6  -  D200A  IS  Input  and  Output  Map 

7  -  DSOR  101  User  Training  (Presentation  Slides) 

8  -  Enterprise  Infonnation  Technology  Data  repository  (EITDR)  Audit  Report 

9-10  USC  Section  2460  “Definition  of  Depot  Level  Maintenance  and  Repair 

10-10  USC  Section  2464  “Core”  Law 

11-10  USC  Section  2466  “50/50”  Law 

12  -  Air  Force  Handbook  (AFH)  23-123  Materiel  Management 

13  -  Air  Force  Instruction  (AFI)  21-118  Maintenance 

14-AFI  63-101/20-101 

15  -  AFI  23-101  Materiel  Management 

16  -  Air  Force  materiel  Command  Instruction  (AFMCI)  21-101  Depot  Maintenance 
Activation  Planning 

17  -  AFMCI  23-101  Acquisition  Management 

18  -  AFMCI  23-104  Functions  and  Responsibilities  of  the  Equipment  Specialist  During 
Provisioning 

19  -  AFMCI  23-109  Applications,  Programs,  and  Indentures 

20  -  AFMCI  23-112  Management  of  Items  Subject  to  Repair  (MISTR) 

21  -  Depot  Maintenance  Senior  Leaders’  Maintenance  Course  (Presentation  slides) 

22  -  DoD  Directive  4151.18  Maintenance  of  Military  Materiel 

23  -  Organic  Depot  Activation  Process  Map 

24  -  TO  00-25-195  AF  Technical  Order  System  Source,  Maintenance  and 

Recoverability  Coding  of  Air  Force  Weapons  Systems  and  Equipments 

25  -  USAF  Supply  Support  A  Team  Approach 

26  -  Global  Combat  Support  System  -  Air  Force  Customer  Service  Guide 

27  -  Product  Support  Tool  Kit  (PSTK) 

28  -  50/50  Data  Flow  Map 

29  -  Acquisition  Lifecycle  Management  Process  Map 

30  -  AFMCI  21-101  Depot  Maintenance  Activation 

31  -  AFMCMAN  23-5  D035A 

35 


Archival  records 


The  records  primarily  involve  the  DSOR  database  going  back  to  the  early  1980s.  The 
DSOR II  contractor  was  still  in  the  process  of  entering  this  data  into  the  DSOR  II  IS  during  the 
case  study.  A  list  of  archival  records  reviewed  in  the  case  study  is  provided  in  Table  7. 


Table  7:  List  of  Archival  Records  Reviewed 


Name  of  Archival  Record 

1  -  Final  DSOR  Decision  Memo  (DSOR  #  13609F) 

2  -  13609F  Joint  DSOR  Decision  Memo  (DSOR  #  13609F) 

3  -  DSOR  Team  50/50  Database 

4  -  Minutes  of  Spares  Provisioning  Conference  for  C-5  AMP  Depot  LRU 

5  -  Meeting  Minutes:  C-5  Modernization  Program  -  Depot  Maintenance 
Activation  Working  Group  (DMAWG) 

6  -  Depot  Activation  Checklist  -  APG-63(V)3  Active  Electronically 
Scanned  Array  Radar  Program 

7  -  Depot  Maintenance  Activation  Working  Group  Charter  -  APG- 
63(V)3  Active  Electronically  Scanned  Array  Radar  Program 

8  -  Depot  Level  Repair  Integrated  Master  Schedule  -  APG-63(V)3  Active 
Electronically  Scanned  Array  Radar  Program 

9  -  Depot  Maintenance  Activation  Plan  -  APG-63(V)3  Active 
Electronically  Scanned  Array  Radar  Program 

10  -  Depot  Repairable  Candidates  List  -  F15E  Radar  Modernization 
Program  System  Development  &  Demonstration  Phase 

1 1  -  Meeting  Minutes  -  APG  79  REX  &  CISP  weapon  system 

12  -  Source  of  Repair  Activity  (SORA)  F-15  LRU  Weapon  System 

13  -  Depot  Military  Inter-service  (DMI)  Worksheet 

Interviews 

A  total  of  17  semi-structured  interviews  were  conducted  to  collect  infonnation  from 
various  stakeholders.  These  stakeholders  include  DSOR  team  members,  Program  Managers, 
Item  Managers,  end-users,  IS  experts,  and  other  process  owners.  The  stakeholder,  interview 
date,  and  interview  method  are  listed  in  Table  8.  The  data  collected  from  the  interviews  are 
stored  in  a  case  study  data  base  and  analyzed  in  Chapter  4.  Personally  identifiable  information  is 
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omitted  to  protect  interview  subjects  from  any  negative  impacts  which  may  arise  from  the 
information  he  or  she  contributed  to  the  case  study. 

Table  8:  List  of  Stakeholder  Interviews 


Stakeholder 

Date 

Interview  Method 

1 :  DSOR  Team  member 

10-Dec-14 

In  person(WPAFB) 

2:  DSOR  Team  member 

10-Dec-14 

In  person(WPAFB) 

3:  DSOR  Team  member 

16-Dec-14 

In  person(WPAFB) 

4:  DSOR  Team  member 

16-Dec-14 

In  person(WPAFB) 

5:  DSOR  Team  member 

11 -Apr- 14 

In  person(WPAFB) 

6:  DSOR  Team  member 

18-Apr-14 

In  person(WPAFB) 

7:  DSOR  Team  member 

18-Apr-14 

In  person(WPAFB) 

8:  Program  Manager  (F-16) 

16-Oct-14 

In  person(WPAFB) 

9:  Program  Manager  (HH-60) 

16-Oct-14 

In  person(WPAFB) 

10:  Program  Manager  (Tinker) 

6-Oct-14 

In  person(WPAFB) 

1 1 :  Item  Manager 

21 -Oct- 14 

Electronic  mail 

12:  Item  Manager 

14-Oct-14 

In  person  (WPAFB) 

13:  Item  Manager 

10-Dec-14 

Telephone 

14:  End  user 

18-Jul-14 

In  person  (WPAFB) 

15:  End  user 

17-Sep-14 

In  person  (WPAFB) 

16:  WebFLIS  IS  expert 

27  Jul  14 

Electronic  mail 

17:  Provisioning  Process  Expert 

15-Dec- 14 

Electronic  mail 

Direct  observation.  Captain  Dipta  Kazi  spent  an  average  of  5-10  hours  most  weeks  at  his 
work  station  with  the  DSOR  team  during  the  period  of  January  2014  to  January  2015.  During 
this  time,  he  worked  on  gathering  infonnation  through  fonnal  and  informal  discussions, 
preparing  for  and  conducting  interviews  and  conducting  research  on  various  USAF  IS.  During 
his  time  at  AFMC,  he  was  able  to  observe  meetings,  infonnal  discussions,  employee  interactions, 
and  assess  the  morale  of  the  work  force.  He  was  able  to  observe  how  employees  dealt  with 
technological  and  workflow  issues  caused  by  the  DSOR  II  IS  and  how  the  employees  addressed 
those  issues. 
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Participant-observation.  Captain  Dipta  Kazi  gained  access  to  the  DSOR II  IS  and 
became  an  active  user.  He  learned  to  navigate  information,  conduct  searches,  and  understand  its 
workflow  process  with  the  help  and  training  of  DSOR  team  members.  He  also  gained  access  to 
multiple  USAF  logistics  IS  to  compare  data.  Description  of  these  IS  are  detailed  in  Table  9. 


Table  9:  IS  Descriptions 


Information  System 

Description 

Depot  Source  of  Repair  II 
Sharepoint  IS  (DSOR  II) 

The  DSOR  II  IS  is  a  standalone  database  used  solely  by  the 
AFMC  A4  DSOR  office  to  manage  their  approvals  Federal 
Logistics  Information  System  Web  Search  (WebFLIS)  -  Joint 
database  of  national  stock  numbers  (NSNs)  managed  by  the 
Defense  Logistics  Agency  designed  to  minimize  multiple  part 
numbers  for  the  same  assets. 

Logistics,  Installations, 
and  Mission  Support  - 
Enterprise  View  (LIMS- 
EV) 

An  Air  Force  enterprise  level  reporting  and  analytics  tool 
spanning  Executive,  Logistics  Readiness,  Requirements, 
Maintenance  Repair  and  Overhaul,  and  Installation  and 

Mission  Support. 

Enterprise  Solution 

Supply  (ES-S) 

ES-S  is  a  supply  tool,  which  provides  role-based  access  to 

Air  Force  logisticians  through  the  Air  Force  portal  and 
integrates  data  from  numerous  legacy  systems  into  one 
interface.  Its  functions  include  data  visibility,  transaction 
processing,  order  management,  shipment  management,  asset 
management  and  asset  redistribution. 

D043A  Master  Item 
Identification  Database 

Allows  menu-driven  interrogation  of  data  derived  from  the 
IMCS  and  other  systems.  It  also  provides  on-line  access  to 
certain  data  segments  of  FLIS.  D043A  enhances  user‘s  ability 
to  perform  research  and  to  identify  and  resolve  logistics  data 
problems  in  support  of  the  AF  mission. 

Navy  DSOR  Depository 

Joint  database  currently  managed  by  US  Navy  DSOR  office 
consisting  of  DSOR  approval  decisions  dating  back  to  the 
late  1980s.  This  database  was  used  by  a  joint  organization 
charged  with  making  DSOR  location  decision.  This  joint 
office  was  dissolved  in  2009  due  to  its  long  review  process, 
which  caused  delays  in  the  acquisition  pipeline.  The  DSOR 
location  decision-making  responsibilities  have  since  been 
delegated  to  the  respective  branches. 

Web  Federal  Logistics 
Infonnation  Service 
(WebFLIS) 

The  WebFLIS  service  from  the  Federal  Logistics  Information 
Service  (FLIS)  of  the  Defense  Logistics  Agency  (DLA)  is  an 
online  search  system  for  several  public  segments  of  the  USA 
Federal  Logistics  Database  for  codified  supplies  that  are 
represented  by  a  pennanent  National  Stock  Number  (NSN). 
(Defense  Logistics  Agency,  2015) 
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Secondary  Item 
Requirement  System 
(SIRS)  (D200A) 


The  primary  function  of  the  D200A  is  Requirements 
Management.  The  SIRS  maintains  visibility  on  all 
recoverable  and  consumable  spares  while  computing  buys 
and  repair  requirements  on  a  quarterly  cycle.  Examples  of 
recoverable  items  include  avionics  subsystems,  ground 
communications  equipment,  and  airborne  electrical  power 
generators.  Provides  indication  of  items  subject  to  buy, 
repair,  termination,  and  disposal.  Provides  online 
maintenance  and  interrogations.  Included  within  this 
subsystem  is  the  ability  to  perfonn  online  item 
recomputations  and  batch  group  recomputations. 
Approximately  200,000  items  are  processed  by  this 
subsystem.  Processes  perfonned  include  maintaining  past 
usage  data,  forecasting  trends  and  applying  programs  and 
assets  in  computing  future  buy  and  repair  requirements 
(Defense  Acquisition  University,  2014). 


Analyze 

The  data  collected  using  the  multiple  sources  listed  above  are  analyzed  in  greater  detail  in 
Chapter  4.  The  analysis  relies  on  theoretical  propositions  found  in  the  literature  review  to 
establish  a  pattern  among  the  data  collected.  The  advantage  to  using  multiple  sources  of  data 
collection  is  being  able  to  verify  and  validate  the  infonnation  used  in  the  case  study  analysis  and 
findings.  It  builds  construct  validity,  a  key  aspect  needed  to  conduct  a  strong  case  study. 


Share 

Once  the  case  study  is  completed,  the  infonnation  will  be  presented  to  the  AFIT 
community  in  this  thesis  report  and  thesis  defense  presentation.  The  DSOR  team  is  an  important 
audience  for  this  case  study  and  will  be  presented  with  this  infonnation  in  a  briefing.  The 
information  found  in  this  case  study  can  be  of  assistance  to  managers  and  supervisors  facing 
similar  IS  issues  discussed  in  this  research.  They  may  find  this  information  in  future  journal 
publications. 
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IV:  Case  Study  Analysis 


The  DSOR  team  observed  multiple  issues  which  needed  to  be  further  researched  and 
addressed  in  this  case  study.  One  of  the  main  issues  identified  by  the  DSOR  team  is  that  the 
DSOR  II  data  is  incomplete  and  unreliable.  There  are  reparable  parts  in  use  throughout  the 
USAF  which  are  not  recorded  in  the  DSOR  II  database.  Many  of  the  parts  that  are  found  in  the 
DSOR  II  database  do  not  have  the  correct  DSOR  location.  This  means  that  there  are  changes 
being  made  to  DSOR  locations  without  approval  from  the  DSOR  team  once  parts  are  in  the 
sustainment  phase.  The  DSOR  II  IS  has  no  means  of  capturing  these  changes  since  it  does  not 
exchange  data  with  any  other  IS. 

Another  significant  challenge  is  that  DSOR  II  users  cannot  search  using  the  same  unit  of 
measure  used  by  most  USAF  supply  chain  stakeholders  and  IS.  When  the  DSOR  request  first 
arrives  to  the  DSOR  team  for  approval,  parts  are  identified  and  recorded  by  its  system  or 
subsystem.  This  means  that  there  would  be  one  DSOR  request  for  an  entire  system  (i.e.  F-22 
aircraft)  or  subsystem  (i.e.  F-22  engine).  The  system  or  subsystem  is  identified  by  the  many 
parts  which  make  up  the  system  or  subsystem  and  given  a  national  stock  number  (NSN).  The 
NSN  is  the  primary  unit  of  measure  used  by  nearly  all  USAF  supply  chain  stakeholder.  This 
disconnect  makes  it  difficult,  if  not  impossible,  to  find  data  within  the  DSOR  II  database. 

The  issues  identified  by  the  DSOR  team  were  all  connected  and  needed  to  be  addressed 
in  conjunction  with  one  another.  Addressing  the  issues  individually  would  not  generate  a  feasible 
solution  to  their  underlying  problem.  The  underlying  problem  of  this  research  is  that  the  DSOR 
team  is  faced  with  a  poor  enterprise-level  IS  and  must  develop  an  IS  which  helps  it  accomplish 
its  mission.  The  literature  review  helps  address  how  an  organization  may  do  just  that.  In 
addressing  the  underlying  problem,  this  case  study  evaluates  the  entire  DSOR  project  and 


40 


uncovers  challenges  beyond  those  identified  by  the  DSOR  team.  These  challenges  are 
interrelated  and  must  be  addressed  in  conjunction  with  one  another  to  truly  mitigate  the 
underlying  issues.  The  findings  from  the  literature  review  are  used  as  a  guide  to  evaluate  the 
DSOR  II  IS.  The  following  sections  detail  the  case  study  findings  in  the  business  case,  IS  design 
and  diffusion  stages  of  the  DSOR  II  program. 

Case  Study  Analytic  Strategy 

The  data  analysis  was  conducted  following  methods  recommended  Yin  (2009).  The  case 
study  is  guided  by  the  research  question,  which  is  broken  into  three  investigative  questions. 

Each  of  the  investigative  questions  is  categorized  into  three  arrays  and  contributes  to  answering 
the  research  question.  The  three  arrays  are  IS  business  case  development,  design  and  diffusion. 
The  literature  review  is  then  used  to  develop  theoretical  proposition  for  each  of  the  investigative 
questions.  These  theoretical  propositions  are  then  combined  to  develop  a  framework  which 
addresses  the  overall  research  question. 

The  data  collected  in  the  case  study  are  categorized  into  the  three  arrays.  In  essence,  a 
matrix  of  the  three  categories  was  created  and  related  evidence  was  placed  within  each  category. 
Various  data  displays  are  created  using  the  data  collected.  The  data  displays  are  used  to 
determine  and  fonnulate  findings  and  information  required  by  the  respective  arrays.  Once  the 
data  was  collected  in  the  case  study  research,  it  is  then  compared  with  the  theoretical  proposition 
developed  before  the  data  was  collected.  This  analytical  technique  is  called  pattern  matching 
(Yin,  2009).  By  applying  the  data  collected  in  the  DSOR  case  study  to  the  theoretical  framework, 
we  made  a  theoretical  replication  to  determine  how  the  DSOR  case  study  may  best  address  the 
research  question  (Yin,  2009).  If  the  case  study  data  analysis  does  not  coincide  with  any  portion 
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of  the  theoretical  framework,  it  is  identified  as  an  area  for  improvement  and  managerial 
implications  are  recommended. 

Business  Case  Development 

Developing  an  effective  business  case  is  an  important  step  to  creating  an  effective  IS. 

The  literature  review  conducted  in  Chapter  2  provides  a  guide  for  how  to  establish  an  IS  business 
case  based  on  existing  research  and  theories.  This  section  uses  the  findings  from  the  literature 
review  to  evaluate  the  DSOR II  IS. 

Align  organizational  and  IS  strategies 

Understanding  the  organizational  mission  and  strategy  is  the  first  step  to  developing  the 
IS  strategy.  The  mission  statement  and  vision  is  fonnalized  by  the  AFMC/A4  office  and  is 
detailed  below  (AFMC/A4,  2014): 

Mission  Statement: 

Shape  the  workforce  and  infrastructure  to  provide  logistics  and  sustainment 
support  for... Acquisition  logistics,  Supply  management,  Depot  maintenance  and 
Base-level  logistics  operations... resulting  in  war- winning  expeditionary 
capabilities 

Vision: 

To  exceed  our  customer  expectations,  providing  the  most  cost  effective,  timely 
and  flexible  logistics  products  and  services  into  the  21st  century 

The  DSOR  team  falls  under  the  acquisition  logistics  and  depot  maintenance  functions  as 
stated  in  the  mission  statement.  Based  on  the  mission  statement  the  DSOR  team  must  aim  to 
provide  war-winning  capabilities  in  its  specific  tasks.  In  accomplishing  its  task,  the  DSOR  team 
is  to  provide  outstanding  service  which  exceeds  customer  expectations,  be  fiscally  responsible, 
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and  be  flexible  in  what  it  does.  The  AFMC/A4  provides  general  guidance  for  what  the 
organization  must  aim  to  do  but  leaves  much  of  the  specific  instructions  up  to  interpretation. 

The  DSOR  team  must  first  identify  its  customer,  and  provide  the  customer  timely  and 
quality  customer  service  in  a  cost  effective  manner  while  maintaining  flexibility  in  its  processes. 
It  is  very  important  to  first  detennine  the  DSOR  team’s  customers.  The  DSOR  team’s  formally 
recognized  customers  are  the  AFMC  community  and  the  joint  logistics  community  (AFMC 
A4D,  2014).  The  organization’s  output  is  part  of  a  larger  acquisition  process  which  aids 
stakeholders  in  the  AFMC  community.  Some  of  its  outputs  aid  stakeholders  outside  of  the 
USAF.  This  is  discussed  in  more  detail  later  in  this  chapter. 

The  AFMC  community,  primarily  Program  Managers,  may  be  the  DSOR  team’s  primary 
customer  but  it  is  not  DSOR  II’s  primary  customer.  The  DSOR  II  IS  is  a  system  which  enables 
the  DSOR  team  to  accomplish  its  tasks  with  input  from  external  stakeholders.  The  output 
produced  with  the  assistance  of  DSOR  II  is  ultimately  used  by  external  stakeholders.  The  DSOR 
II  workflow  process  tool  does  not  assist  other  stakeholders  in  accomplishing  their  tasks,  only  the 
DSOR  team  tasks.  The  DSOR  team  requires  external  stakeholders  to  interact  with  DSOR  II  to 
enable  its  mission  and  provide  a  service.  It  does  not  matter  to  the  stakeholders  if  DSOR  II  is 
used  to  produce  the  output  as  long  as  it  receives  the  approval  memo,  report  or  support  provided 
by  the  DSOR  team.  The  issue  of  the  DSOR  team’s  customers  is  discussed  in  a  later  section. 

This  section  takes  the  broad  organizational  strategy  set  as  provided  by  the  AFMC/A4  and 
develops  an  IS  strategy  set  for  the  DSOR  II  project. 

The  DSOR  II  strategy  set  must  include  the  system  objectives,  a  list  of  its  constraints,  and 
a  strategy  for  executing  the  IS  strategy.  The  current  DSOR  II  system  objectives  are  (AFMC 
A4D,  2014): 
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1 .  Utilize  MS  SharePoint  to  execute  standardized  DSOR  Workflow  Process  within 
AFMC  community 

2.  Allow  for  joint  expansion  into  other  DoD  agencies 

3.  Generate  ad  hoc  reports  to  support  execution  &  management  of  AFMC  Workflow 
processes 

4.  Produce  financial  reports  of  DoD  Depot  Repair  Program  to  help  ensure  compliance 
with  Title  10  Laws 

5.  Provides  audit  trail/documents  source  of  repair  (SOR)  decision  for  life  of  the  system 

Some  of  the  constraints  and  challenges  an  IS  with  these  objectives  would  face  are 

exceeding  the  organization’s  scope  and  authority,  integrating  any  legacy  systems,  inter¬ 
departmental  collaboration,  funding,  business  process  knowledge,  infonnation  technology 
expertise,  IS  compatibility  and  interoperability,  and  user  acceptance.  These  are  all  issues  that  the 
DSOR  team  must  address  to  field  an  effective  IS  and  are  discussed  throughout  this  chapter.  The 
strategy  to  develop  the  DSOR  II  IS  is  to  outsource  the  development  and  maintenance  of  the 
DSOR  II  software  through  a  government  contract.  This  is  the  optimal  strategy  because  of  their 
lack  of  organic  software  engineering  capability. 

The  managerial  implication  is  to  align  the  DSOR  team’s  organizational  and  IS  strategies. 
In  order  to  do  that,  the  DSOR  team  must  focus  its  resources  on  making  the  DSOR  II  an  effective 
IS  for  the  DSOR  team.  Details  on  how  it  may  make  DSOR  II  a  more  effective  tool  is  provide 
later  in  this  chapter.  The  DSOR  II  project  must  prioritize  the  DSOR  II  team  as  its  primary 
stakeholder  before  focusing  on  the  AFMC  community  or  other  service  branches. 

Enlist  support  at  appropriate  level 

The  literature  review  established  that  it  is  important  for  an  IS  project  to  be  led  with  the 
proper  authority  and  scope.  The  DSOR  II  is  designed  to  help  the  DSOR  team  accomplish  its 
tasks  and  produce  an  output  which  helps  the  AFMC  community  execute  the  larger  acquisition 
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process  and  effectively  manage  the  USAF  supply  chain.  It  would  not  be  useful  to  implement 
DSOR II  as  a  DSOR  database  and  workflow  process  management  tool  to  other  services  without 
significant  improvements  to  its  current  state.  The  DSOR  II  database  capabilities  are  inaccurate, 
incomplete  and  require  managerial  attention  before  it  can  be  of  use  to  the  DSOR  team,  let  alone 
external  stakeholders.  The  DSOR  II’s  workflow  process  management  functions  also  needs 
significant  adjustments  and  is  not  ready  for  joint  use. 

A  simplified  organizational  structure  is  shown  in  Figure  8.  This  structure  depicts  where 
the  DSOR  team  falls  within  the  DoD  organizational  structure  and  where  the  other  key  DSOR 
stakeholders  work.  The  DSOR  team  is  not  in  a  position  of  having  the  necessary  strategic 
outlook,  financial  resources,  technical  expertise,  business  process  knowledge,  or  authority  to 
implement  an  inter-service  IS  across  the  DoD.  Once  the  DSOR  II  IS  database  and  workflow 
functions  are  improved,  the  DSOR  project  team  may  elevate  a  business  case  up  to  the  DoD 
leadership  atop  its  organizational  structure. 


Figure  8:  DSOR  Team  Organizational  Structure 
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Evaluate  Organizational  Capabilities 


Evaluating  the  organization’s  capabilities  is  an  important  part  of  establishing  what  type  of 
IS  will  be  required  and  the  resources  needed  to  make  it  successful.  The  literature  review  found  a 
list  of  uncontrollable,  partially  controllable,  and  fully  controllable  factors  which  help  evaluate  the 
organization’s  capabilities.  The  factors  which  were  evaluated  as  potential  issues  in  the  effective 
management  of  the  DSOR  II  program  are  marked  with  a  grey  box  in  Table  10.  These 
capabilities  were  analyzed  and  evaluated  using  infonnation  from  DSOR  team  member  interviews 
and  infonnal  discussions,  direct  observations,  documents,  archival  records,  and  user 
participation. 


Table  10:  DSOR  Team  Organizational  Capabilities  Analysis 


Uncontrollable  factors 

Organizational  size 

Organizational  structure 

Organizational  time  frame 

Extra-organizational  situation 

IT  products  in  market 

External  expertise  &  service  availability  &  support 

Process  compatibility 

Partially  controllable  factors 

Firm’s  knowledge  resources 

Financial  resource  availability 

Organization’s  technical  expertise 

Knowledge  acquisition/ application/ sharing 

CEO’s  support  and  commitment 

Organizational  maturity 

Organizational  climate 

Fully  controllable  factors 

Training  availability 

Steering  committee 

Users’  participation  and  involvement 

Integration  of  internal  processes 
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The  organizational  factors  which  pose  the  most  immediate  threat  to  the  successful 
development  and  implementation  of  the  DSOR  process  are  process  compatibility,  Ann’s 
knowledge  resources,  financial  resource  availability,  organization’s  technical  expertise, 
organizational  climate,  the  steering  committee,  user’s  participation  and  involvement,  and 
integration  of  internal  processes.  While  these  are  significant  challenges,  there  are  mitigation 
methods  available  to  address  the  issue  and  make  DSOR  II  an  effective  IS.  None  of  these  issues 
give  cause  to  abandon  the  project. 

Process  Compatibility.  There  are  multiple  business  processes  performed  by  the 
DSOR  team  which  are  not  incorporated  into  the  DSOR  II  workflow  management  tool.  These 
processes  are  discussed  in  greater  detail  later  in  this  chapter.  Most  of  those  processes  are 
controllable  and  may  be  addressed  internally.  The  process  which  cannot  be  controlled  by  the 
DSOR  team  is  the  acquisition  process  for  the  Navy,  Anny  and  Marines.  In  order  for  DSOR  to  be 
truly  joint  and  of  benefit  to  other  branches,  the  DSOR  team  must  align  the  separate  processes  for 
DSOR  approval  and  incorporate  it  into  DSOR  II.  This  is  not  an  impossible  task  but  is  something 
which  must  be  led  by  an  organization  with  higher  authority  within  the  DoD.  Further  research 
should  be  conducted  to  map  the  DSOR  process  of  the  other  services.  The  DSOR  team  would 
need  to  elevate  its  efforts  to  standardize  the  DSOR  approval  process  throughout  the  DoD  and 
gain  DoD  leadership  support  to  shape  DSOR  II  into  a  truly  joint  IS. 

Firm ’s  Knowledge  Resources.  The  DSOR  II  project  team  is  challenged  with 
streamlining  a  portion  of  a  complex  acquisition  process.  It  can  be  challenging  to  capture  the  roles 
of  all  the  stakeholders  in  the  DSOR  process  well  enough  to  build  an  IS  to  manage  its  workflow. 
There  are  some  challenges  to  developing  cross-functional  processes  and  IS.  The  way  to  address 
this  knowledge  gap  is  to  include  other  stakeholders  in  the  project  team.  Different  stakeholders 


47 


will  contribute  a  perspective  which  is  valuable  to  the  development  and  implementation  of  an 
effective  IS. 

Financial  Resource  Availability.  Any  changes  to  the  DSOR  II  contracts  which 
may  require  additional  work  will  require  more  funding.  This  is  an  important  factor  in  scoping 
the  IS  design.  There  is  no  point  in  designing  an  IS  which  the  organization  cannot  afford.  The 
DSOR  II  project  team  must  consider  the  potential  for  funding  any  deviations  from  the  current 
contract  before  pursuing  design  changes  or  improvements. 

Organizational  Technical  Expertise.  The  DSOR  team’s  IS  technical  expertise 
resides  in  the  contractors  which  manage  DSOR  II.  It  is  important  to  have  IS  technical  experts  in 
the  project  team  to  help  develop  a  strategy  and  the  requirements  for  the  IS.  There  is  no  technical 
software  or  MS  Sharepoint  expertise  on  the  DSOR  II  project  team.  There  are,  however, 
technical  experts  within  the  AFMC  staff  which  may  be  helpful  in  managing  the  DSOR  II  project. 

Organizational  climate.  A  recent  downsizing  of  the  HQ  AFMC  staff  has  led  to 
the  loss  of  a  position  within  the  DSOR  team.  This  development  has  impacted  the  team’s  morale, 
which  may  contribute  to  its  resistance  to  new  innovation  and  changes.  It  is  important  to  take 
these  factors  into  consideration  before  introducing  new  changes.  Overall,  the  DSOR  team  has 
good  leadership  and  morale  is  high.  The  work  environment  is  relaxed  and  people  are 
comfortable  communicating  with  one  another. 

Steering  Committee.  The  DSOR  II  project  team  does  not  include  all  internal  or 
external  stakeholders.  It  should,  at  a  minimum,  include  members  from  each  of  the  DSOR  team’s 
sub-sections  (DMI,  SORA,  DAC,  CCD),  at  least  one  program  manager  and  item  manager.  This 
type  of  collaboration  will  be  effective  in  developing  a  useful  IS  and  addressing  much  of  the 
current  issues. 
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User  Participation  and  Collaboration.  The  DSOR  II  IS  does  not  incorporate  all 
the  processes  managed  by  the  DSOR  team.  This  has  led  to  DSOR  team  members  developing 
their  separate  excel  databases  and  processes  which  are  managed  outside  of  DSOR  II.  This  lack 
of  participation  has  led  to  little  collaboration.  This  is  not  the  fault  of  the  members  but  the  IS  for 
not  addressing  their  needs.  The  DSOR  II  IS  needs  to  incorporate  all  the  processes  executed  by 
the  DSOR  team  in  order  for  them  to  find  value  in  it. 

Integration  of  Internal  Processes.  As  mentioned  in  the  paragraph  above,  DSOR 
II  does  not  capture  all  processes  of  the  DSOR  team.  There  was  another  significant  process  gap 
which  needs  to  be  addressed.  When  DSOR  requests  arrive  to  the  DSOR  team,  the  program  is 
still  in  the  system  or  subsystem  level  (i.e.  F-16  aircraft,  or  F-16  aircraft  engine).  Later  on  in  the 
larger  acquisition  process,  after  the  DSOR  has  been  approved,  the  weapon  system  is  broken 
down  into  parts  or  NSNs.  The  end  users’  unit  of  measure  is  in  parts,  not  system  or  subsystem. 
The  USAF  operates  using  NSNs  while  the  DSOR  II  database  contains  records  using  system  or 
subsystem.  This  makes  it  difficult  to  search  of  parts  by  its  national  stock  number  (NSN)  in 
DSOR  II.  The  DSOR  II  team  members  have  to  search  in  other  databases  to  find  the  infonnation 
they  need.  DSOR  II  database  is  using  a  different  unit  of  measure  than  the  rest  of  the  USAF 
supply  chain  because  of  its  current  process.  The  DSOR  team  must  input  records  in  terms  of  parts 
or  tie  its  DSOR  approval  number  to  the  individual  part  in  order  to  address  this  issue.  If  the 
USAF  logistics  IS  contained  this  approval  number  under  each  part  or  NSN,  the  DSOR  team  can 
connect  the  part  to  the  corresponding  DSOR  approval. 

Map  Information  Flow 

Understanding  how  the  information  must  flow  inside  and  outside  the  organization  is  a 
critical  part  of  designing  an  effective  IS.  Part  of  the  case  study  is  understanding  the  infonnation 
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flow  of  each  process  conducted  by  the  DSOR  team  and  mapping  how  the  infonnation  flows  in 
executing  those  processes.  The  data  sources  to  determine  the  information  flow  for  each  of  the 
DSOR  process  is  listed  in  Table  11. 


Table  11:  Information  Process  Flow  List  of  Sources 


Process 

Source 

DSOR  Approval 

AFMC/A4DC,  2014 

AF/AQXA,  2013 

DMAWG  Support 

AFLCMC/LG,  2014 

AFMC/A4DC,  2012 

DSOR  Team  Member  #3,  2014 

DSOR  Team  Member  #4,  2014 

Periodic  Review 

AFMC/A4DC,  2014 

AF/AQXA,  2013 

DSOR  Team  Member  #5,  2014 

DSOR  Team  Member  #6,  2014 

Joint  DMI 

DSOR  Team  Member  #7,  2014 
AFMC/A4DC,  2014 

AFMC/A4DC,  2012 

Annual  Budget  Reporting 

AFMC/A4D,  2011 

DSOR  Team  Member  #2,  2014 

Office  of  the  Secretary  of  Defense,  2013 

The  DSOR  team  has  five  processes  which  produce  five  different  outputs  for  various 
USAF  supply  chain  stakeholders.  The  first  and  primary  process  of  DSOR  II  is  the  DSOR 
approval  process.  This  is  the  process  in  which  PMs  initiate  a  DSOR  approval  request  in  DSOR 
II.  The  DSOR  team  performs  its  tasks  and  obtains  AFMC/A4  director  approval  (this  authority  is 
given  to  the  AFMC  Commander  and  has  been  delegated  to  AFMC/A4  director).  There  are 
multiple  tasks  perfonned  by  the  DSOR  team  in  this  approval  process  which  are  managed  outside 
the  DSOR  II  IS.  These  sub-tasks  are  performed  outside  of  DSOR  II  because  it  is  not  designed  to 
perfonn  those  tasks  or  the  sub-tasks  are  too  difficult  to  integrate  into  the  DSOR  II  workflow. 
Once  the  DSOR  memorandum  is  signed,  it  is  sent  back  to  the  PM  to  continue  on  to  the  next  step 
of  the  acquisition  process. 
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The  next  process  is  providing  support  to  the  Depot  Maintenance  Activation  Working 
Group  (DMAWG).  The  DMAWG  works  as  a  planning  group  of  all  necessary  stakeholders  to 
ensure  funding,  contracting,  and  delivery  of  the  data  required  to  establish  depot  repair  capability. 
A  member  of  the  Depot  Activation  Cell  (DAC)  is  involved  in  the  DMAWG  to  provide  support  to 
the  PM  and  ensure  the  requirements  have  not  changed  enough  to  require  a  new  DSOR  approval. 
This  support  requires  attending  meetings,  conferences,  and  correspondence.  This  process  simply 
involves  providing  support  to  the  DMAWG  in  case  a  DSOR  shift  is  needed. 

A  periodic  review  of  each  weapons  system  or  DSOR  approval  is  required  every  five 
years.  The  DAC  currently  conducts  the  review  every  three  years.  The  periodic  review  involves 
working  with  the  PM  to  assess  and  revalidate  the  initial  strategy  as  set  by  the  program  office 
(AF/AQXA,  2013).  The  periodic  review  may  result  in  adjusting  resources  and  requirements 
based  on  perfonnance  and  war-fighter  needs.  The  DSOR  II  IS  initiates  the  periodic  review  of 
DSORs  approved  three  years  ago  and  prompts  the  DAC  to  obtain  information  from  the  PM 
whom  updates  the  project  funding  data.  This  process  is  performed  very  well  in  DSOR  II. 

The  Joint  DMI  process  is  the  DSOR  team  providing  concurrence  with  the  Army,  Navy, 
or  Marine  DSOR  team’s  DSOR  decisions.  Once  the  DMI  section  receives  a  concurrence  request 
via  email,  it  validates  whether  the  USAF  has  the  same  repair  capability.  The  process  is  set  up  to 
ensure  the  DoD  minimizes  unintended  duplication  of  depot  repair  capabilities  across  the 
services.  The  DMI  section  responds  with  its  concurrence  once  it  determines  the  USAF  does  not 
have  a  similar  capability.  It  is  rare  for  any  of  the  service  to  non-concur  with  another  services’ 
request  for  concurrence  (DSOR  Team  Member  #7,  2014).  This  process  is  conducted  outside  of 
DSOR  II. 
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The  annual  budget  reporting  process  is  another  process  conducted  outside  of  DSOR II. 
The  CCD  team  collects  financial  infonnation  from  14  various  USAF  supply  chain  stakeholders 
every  November  to  report  the  USAF  depot  repair  expenditures  and  future  budget  to  the  Office  of 
the  Secretary  of  Defense  (OSD)  by  the  following  March.  The  OSD  then  compiles  the  report 
from  each  service  to  report  to  Congress  (AFMC/A4DC,  2014). 

The  five  processes  executed  by  the  DSOR  team  are  summarized  in  a  process  map  in 
Figure  9.  Each  of  the  five  rows  represents  a  separate  process.  The  first  column  indicates  the 
stakeholder  from  which  the  DSOR  team  receives  the  infonnation  or  request  necessary  to  execute 
the  process.  The  input  column  indicates  the  information  given  to  the  DSOR  team.  The  third 
column  indicates  which  sub-section  within  the  DSOR  team  receives  the  infonnation.  The  fourth 
column  indicates  the  output  or  service  provided  by  the  DSOR  team.  The  fifth  column  indicates 
the  customer  or  USAF  supply  chain  stakeholder  that  receives  the  DSOR  team’s  service.  The 
information  flow  in  the  figure  is  indicated  by  either  a  solid  or  a  dashed  line.  The  solid  line 
means  that  the  information  or  task  is  conducted  in  the  DSOR  II  IS.  The  dashed  line  means  the 
task  is  completed,  or  the  information  is  shared,  outside  of  DSOR  II.  Generally,  this  means  the 
information  is  being  communicated  via  e-mail  or  stored  in  an  individual  excel  database  outside 
of  the  DSOR  II  IS. 
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DSOR  Team 


1  Executed  in  DSOR  II  —  — >  Not  executed  in  DSOR  II 

Figure  9:  DSOR  Process  &  Information  Flow  (Internal) 


Determine  Business  Process  Reengineering  (BPR)  Feasibility 
Determining  the  feasibility  of  business  process  re-engineering  is  essential  to  the 
successful  implementation  of  an  IS.  This  case  study  maps  out  the  USAF  DSOR  process  from 
acquisition  to  sustainment.  The  data  sources  used  to  determine  each  DSOR  process  in  the 
acquisition  system  is  listed  in  Table  12. 
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Table  12:  DSOR  Information  Flow  List  of  Sources 


Process 

Source 

Program  Manager  Initiates 
DSOR 

AFMC/A4DC,  2014 

AF/AQXA,  2013 

AFLCMC/LG,  2014 

DSOR  Team  Approves 
DSOR 

DSOR  Team  Member  #1,  2014 

AF/AQXA,  2013 

AFMC/A4DC,  2012 

Program  Manager  Initiates 
DMA  W  G/Provisioning 

AFMC/A4DC,  2014 

AFMC/A4DC,  2012 

DSOR  Team  Member  #3,  2014 

DSOR  Team  Member  #4,  2014 

Depot  Activation 

AFLCMC/LG,  2014 

AF/AQXA,  2013 

Program  Manager  #1,  2014 

Equipment  Specialist 
inputs  DSOR  data  into 

D200 

AFLCMC/LG,  2014 

Provisioning  Process  Expert,  2014 

D200  collaborates  data 
with  other  IS  once  the  part 
is  fielded  and  requires 
sustainment 

AF/A4LM,  2013 

End  User  #1,  2014 

The  DSOR  process  begins  with  the  PM  initiating  a  DSOR  approval  request  to  the  DSOR 
team.  The  DSOR  team  then  executes  its  internal  process  to  obtain  approval  from  the  AFMC/A4 
Director.  This  approval  is  then  sent  back  to  the  PM,  whose  next  step  is  to  initiate  the  DMAWG 
and  provisioning  processes.  There  is  no  standardized  IS  which  manages  the  information  and  the 
tasks  involved  in  executing  the  DMAWG  and  provisioning  processes.  Once  provisioning  is 
complete,  the  depot  repair  capability  is  activated.  This  step  is  also  conducted  using  an 
independent  IS.  During  the  activation  process,  the  equipment  specialist  inputs  part  information, 
to  include  DSOR  location,  into  the  D200A  IS.  The  D200A  shares  information  with  a  vast 
network  of  IS  which  make  up  the  USAF  supply  chain  IS  network.  Some  of  the  notable  IS  with 
which  DSOR  stakeholders  interact  includes  LIMS-EV,  WebFLIS,  ES-S,  and  D043A.  The 
DSOR  information  flow  is  mapped  in  Figure  10. 
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Figure  10:  DSOR  Information  Flow  (External) 


The  DSOR  business  process  does  not  allow  for  information  to  be  updated  in  DSOR  II 
once  the  weapon  system  is  in  the  sustainment  stage.  The  systems  are  not  integrated  to  exchange 
data  with  DSOR  II.  There  are  two  potential  solutions  to  this  issue.  The  simpler  of  the  two 
would  be  to  add  a  field  in  D200A  and  subsequent  IS  which  shows  the  DSOR  approval  number. 
This  DSOR  approval  number  may  be  used  to  link  individual  parts  to  the  DSOR  approval  stored 
in  the  DSOR  II  database.  This  solution  would  require  some  process  changes  on  the  part  of  the 
PM  and  equipment  specialist.  It  would  also  require  a  technical  change  to  the  D200A  IS  and 
other  IS  to  add  a  field  of  entry  in  its  interface.  The  second  solution  is  to  change  the  DSOR  II 
database  and  record  data  by  NSN.  This  would  allow  for  data  exchange  with  other  systems.  The 
D200A  IS  is  the  recommended  system  to  collaborate  information  with  DSOR  II. 


IS  Design 

An  effective  IS  must  have  certain  features  and  qualities  which  make  it  useful  and 
effective  before  it  can  be  implemented  in  the  organization.  The  literature  review  on  IS  design 
functions  revealed  there  are  four  primary  functions  that  are  essential  to  a  successful  IS.  These 
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features  involve  data  quality,  system  quality,  interoperability,  and  end-user  requirements.  These 
features  and  functions  were  identified  in  the  literature  review  as  contributors  to  an  effective  IS 
and  critical  to  successful  implementation  of  an  IS.  The  literature  review  also  revealed  that 
project  manager  must  adopt  good  project  management  practices.  The  following  sections  will 
evaluate  how  well  the  DSOR II  IS  complies  with  the  good  software  engineering  functions  and 
features  and  whether  the  project  management  team  is  using  good  project  management  practices. 

Adopt  good  project  management  practices 

The  DSOR  II  IS  project  is  in  its  sixth  year  of  development.  The  project  team  is  beyond 
the  initial  stages  of  project  management.  The  current  state  of  the  project  is  being  managed 
satisfactorily  according  to  the  recommendations  in  the  literature  review.  T  he  DSOR  II  has  had 
over  five  years  to  be  properly  structured  and  for  the  project  manager  to  understand  its 
requirements.  Informal  discussions  with  the  project  manager,  participant  observation  of  project 
team  meetings  and  formal  interviews  have  revealed  the  following  infonnation: 

1 .  The  project  team  is  using  Microsoft  Project  to  set  objectives  and  milestones. 

2.  The  project  manager  holds  meetings  as  necessary  with  the  appropriate  stakeholder 
(DSOR  Team  Member  #1,  2014). 

3.  There  is  a  lack  of  a  project  management  team  with  representation  from  each  of  the 
key  IS  stakeholders  (DSOR  Team  Member  #5,  2014). 

The  key  finding  is  that  the  project  team  must  incorporate  key  stakeholders,  both  internal 
and  external,  in  periodic  meetings  to  develop  and  improve  the  IS.  The  DSOR  II  project  is  being 
well  managed  by  the  project  manager  under  its  current  requirements.  Part  of  the  managerial 
implications  resulting  from  this  study  may  recommend  the  DSOR  team  change  DSOR  II 
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requirements  or  focus  elsewhere.  Any  change  in  management  priorities  will  require  the  project 
manager  to  adjust  his  management  approach. 

Employ  Software  Design  Practices 

An  effective  IS  must  have  accurate  data  upon  which  the  users  and  the  organization  can  rely. 
Without  quality  data,  the  IS  is  obsolete  and  will  not  be  useful  to  any  stakeholder  involved.  The 
system  must  also  be  of  good  quality  in  tenns  of  speed,  availability  and  reliability.  An  IS  which 
consistently  hampers  the  users’  ability  to  access  information  and  perfonn  their  job  will  likely 
fail.  The  IS  also  needs  to  be  interoperable  with  other  IS  if  necessary.  A  standalone  IS  can  easily 
become  outdated  and  make  the  business  process  and  data  management  more  difficult.  Lastly,  the 
IS  needs  to  meet  end-user  requirements.  This  involves  technical  and  social  requirements.  The 
technical  aspect  of  user  requirements  involve  having  a  user-friendly  interface,  incorporating  the 
users’  tasks  and  process  within  the  IS,  and  helping  users  perfonn  his/her  job  with  more  ease. 

The  following  sections  evaluate  how  well  DSOR  II  achieves  these  four  functions. 

Data  Quality.  The  DSOR  team  identified  the  quality  of  data  stored  in  the  DSOR 
II  database  function  as  poor  and  unreliable.  Users  have  to  search  other  databases  such  as  LIMS- 
EV,  WebFLIS  and  even  commercial  search  engines  to  find  information  on  parts.  In  order  to 
identify  the  data  quality  of  the  DSOR  II  database,  the  case  study  compared  the  DSOR  data  in 
DSOR  II,  ES-S,  LIMS-EV,  Navy  Depository,  D043A  and  WebFLIS. 

Four  USAF  weapons  systems  were  selected  for  this  data  quality  analysis.  Two  aircraft 
are  fighters  and  two  are  cargo  aircraft.  The  F-16  aircraft  represents  an  older  fighter  aircraft  while 
the  F-22  represents  a  newer  acquisition.  The  C-130  represents  an  older  cargo  aircraft  while  the 
C- 17  is  a  newer  acquisition.  At  least  10  parts  (NSNs)  from  each  aircraft  were  selected,  five  of 
which  were  the  most  critical  parts  in  2013  (known  as  “mission  capable”  or  “MICAP”  parts).  The 
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rest  of  the  parts  were  chosen  at  random.  The  study  included  10  F-16  parts,  10  C- 130  parts,  10  F- 
22  parts  and  13  C-17  parts  for  a  total  of  43  parts.  The  DSOR  location  listed  in  each  of  the  six  IS 
was  captured  and  compared  to  one  another.  The  DSOR  II  data  matched  ES-S  23%  of  the  time, 
LIMS-EV  14%  of  the  time,  the  Navy  Depository  55.8%  of  the  time,  D043A  21%  of  the  time  and 
WebFLIS  21%  of  the  time  and  D200A  21%  of  the  time. 

The  DSOR  II  database  matched  a  reliable  source  (D200A)  only  21%  of  the  time. 

Another  key  finding  is  that  a  third  of  the  parts  could  not  be  found  in  DSOR  II.  This  can  be 
attributed  to  the  fact  the  part  is  simply  not  recorded  or  that  the  DSOR  II  system  does  not  record 
DSOR  data  by  NSNs.  A  list  of  the  NSNs  used  in  the  analysis  is  provided  in  Appendix  8.  The 
DSOR  data  comparison  across  six  other  IS  shows  the  DSOR  II  database  is  both  unreliable  and 
incomplete.  The  percentage  of  parts  which  matched  across  each  of  the  IS  and  the  percentage  of 
parts  which  could  not  be  found  in  the  IS  is  shown  in  Table  13. 


Missing  NSN 

32.6% 

4.7% 

7.0% 

48.8% 

2.3% 

2.3% 

2.3% 


Table  13:  DSOR  Data  Comparison 


Matching  DSOR  Location 

DSOR  II 

ESS 

LIMS-EV 

Navy  Dep 

D043A 

WebFLIS 

D200A 

DSOR  II 

- 

- 

- 

- 

ESS 

23.3% 

- 

- 

- 

LIMS-EV 

14.0% 

69.8% 

- 

- 

- 

- 

fMavy  Dep 

55.8% 

11.6% 

4.7% 

- 

- 

- 

- 

D043A 

20.9% 

62.8% 

67.4% 

9.3% 

- 

WebFLIS 

20.9% 

62.8% 

67.4% 

9.3% 

100.0% 

- 

- 

D200A 

20.9% 

74.4% 

41.8% 

1  9.3% 

79.0% 

79.0% 

- 

Another  measure  of  data  quality  is  the  financial  infonnation  entered  in  to  DSOR  II  during 
the  DSOR  approval  process.  The  initial  projections  submitted  by  the  PMs  are  not  very  accurate 
in  comparison  to  the  expenditures  once  the  weapon  system  is  in  the  sustainment  stage.  The  first 
year  expenditures  projected  by  the  program  office  was  found  to  be  accurate  about  1%  of  the  time 
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between  fiscal  year  1998  through  2012  (AFMC/A4DC,  2014).  This  discrepancy  is  significant 
and  shows  the  poor  reliability  of  DSOR  II’s  financial  data.  The  projected  financial  data  cannot 
be  used  for  reporting  purposes  or  to  make  managerial  decisions. 

System  Quality.  There  are  numerous  system  quality  issues  with  the  DSOR  II  IS. 
This  analysis  is  based  on  DSOR  team  member  interviews  and  discussions,  user  participation,  and 
direct  observation.  One  of  the  most  common  issues  with  DSOR  II  is  that  it  is  slow  to  open  and 
respond  to  user  commands.  This  leads  to  user  frustration  and  loss  of  confidence  in  the  system. 
Another  issue  is  the  interface.  The  DSOR  II  Sharepoint  site  can  be  accessed  through  the  Internet 
Explorer  web  browser.  In  order  to  search  the  DSOR  database,  users  must  download  an  access 
file  onto  his/her  local  hard  drive  and  search  for  data  in  a  separate  Microsoft  Access  window. 

Users  have  come  to  expect  better  interface  and  database  management  from  other  USAF 
Sharepoint  tools.  The  USAF  Evaluation  Management  System  (EMS),  Management  Internal 
Control  Toolsets  (MICT),  and  Task  Management  Tool  (TMT)  are  good  examples  of  Sharepoint 
tools  and  systems  with  user  friendly  interface  and  reliable  software  systems.  It  is  important  for 
the  DSOR  team  to  identify  the  reason  for  the  poor  system  quality  and  work  with  the  contractor  to 
address  these  issues.  An  IS  expert  from  the  AFMC  staff  should  be  present  in  coordinating  with 
the  DSOR  II  contractor  to  improve  the  system  quality  deficiencies.  An  internal  IS  expert  would 
be  able  to  communicate  technical  requirements  and  ensure  those  requirements  are  within  the 
USAF  Sharepoint  capabilities. 

Interoperability.  The  DSOR  II  IS  is  not  interoperable  with  any  other  IS.  Data 
from  DSOR  II  is  manually  updated  in  Navy  Depository  every  quarter  but  does  not  “push”  or 
“pull”  data  from  any  other  source.  If  it  is  not  entered  or  modified  manually,  the  data  remains 
unchanged.  The  lack  of  integration  with  other  IS  has  led  to  incomplete,  inaccurate  and  outdated 
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data.  It  will  be  a  challenge  to  collaborate  and  update  data  with  other  system  because  other 
systems  store  infonnation  by  parts  or  NSNs  while  the  DSOR  II  stores  records  in  units  of  systems 
or  subsystems.  In  order  to  integrate  DSOR  II  with  other  IS,  the  DSOR  database  needs  to  record 
parts  by  NSN.  To  break  each  system  or  subsystem  into  parts  will  take  a  significant  amount  of 
effort  and  time.  Once  DSOR  II  data  are  broken  into  NSNs,  the  system  may  be  set  up  to 
exchange  information  with  the  D200A  system. 

Making  DSOR  II  interoperable  with  any  other  IS  could  be  an  expensive  task.  It  is 
important  to  determine  the  availability  of  funds  that  will  be  required  to  expand  the  scope  of  the 
program.  The  added  storage  requirements,  bandwidth  and  maintenance  of  the  system  will  all 
contribute  to  the  increased  cost  of  integrating  DSOR  II  with  other  systems. 

End-user  Requirements.  The  DSOR  II  IS  can  benefit  from  getting  users  more 
involved  in  making  improvements.  First,  it  needs  to  incorporate  all  the  processes  conducted  by 
the  DSOR  team.  Currently,  DSOR  II  only  incorporates  part  of  the  processes  users  must  execute 
to  accomplish  their  job.  Partial  task  management  means  users  have  to  use  a  different  system  or 
method  to  complete  his/her  other  tasks.  If  the  users  do  not  find  the  IS  beneficial  to 
accomplishing  their  job,  it  will  reduce  their  involvement  and  use  of  the  system. 

End-user  requirements  can  be  improved  with  greater  customer  involvement  and  support. 
The  DSOR  II  IS  must  provide  users  better  feedback  on  their  performance  and  improve 
communication  within  the  department.  These  two  social  functions  will  help  users  better  identify 
with  the  tasks  and  increase  job  satisfaction. 

Diffusion 

Once  the  business  case  has  been  established  and  the  IS  is  designed  and  developed,  the 
organization  is  challenged  with  effectively  incorporating  the  IS  in  the  organization.  The  sections 
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below  use  findings  from  the  literature  review  to  analyze  key  aspects  to  successfully  diffusing 
DSOR II  within  the  DSOR  team.  These  findings  include  using  influential  leadership  support, 
establishing  formal  guidance,  providing  adequate  training  and  support,  and  implementing 
feedback  and  continuous  improvement  methods. 

Influential  leadership  support 

The  DSOR  II  program  has  good  leadership  support  within  the  AFMC/A4  structure  to 
perfonn  its  mission  as  for  the  AFMC  community.  The  current  project  team  does  not  have  the 
level  of  support  and  influence  to  implement  DSOR  II  across  the  other  services.  One  minor 
recommendation  is  to  further  communicate  the  benefits  and  operational  capabilities  of  DSOR  II. 
This  type  of  communication  may  enhance  user  opinion  of  the  IS. 

Establish  Formal  Guidance 

The  DoD  as  a  whole  does  a  good  job  of  establishing  fonnal  guidance  for  its  programs  and 
systems.  This  is  also  the  case  for  the  DSOR  II  program.  The  DSOR  team  has  fonnalized  DSOR 
II  within  the  organization  through  its  training  program  and  process  integration.  Users  have  a 
firm  understanding  of  how  they  are  expected  to  use  DSOR  II.  The  DSOR  team  also  included 
DSOR  II  on  the  Enterprise  Information  Technology  Data  Repository  (EITDR)  to  formally 
recognize  it  as  an  official  USAF  IS.  There  are  no  recommendations  for  establishing  fonnal 
guidance. 

Provide  adequate  user  training  &  support 

Training  is  an  important  part  of  gaining  user  acceptance  and  implementing  an  effective 
IS.  The  DSOR  team  members  received  initial  training  when  the  program  was  first  fielded  and 
they  continue  to  provide  other  stakeholders  face-to-face  training  as  needed.  Overall,  the  DSOR 
II  program  initial  training  efforts  are  to  be  praised. 
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One  aspect  that  is  lacking  is  refresher  training.  Users  are  knowledgeable  of  their  tasks 
and  little  else.  There  is  little  to  no  overlap  of  individual  tasks  because  members  are  comfortable 
with  their  responsibilities.  This  tunnel  vision  of  tasks  creates  an  issue  of  relying  too  much  on 
one  individual  to  accomplish  tasks,  and  ultimately  the  mission.  There  are  several  tasks  within 
the  DSOR  processes  that  can  be  accomplished  by  one  individual  alone.  It  is  risky  not  to  have 
overlapping  capabilities  in  case  any  of  those  individuals  are  unavailable  for  any  length  of  time. 

Improved  refresher  training  and  cross  training  will  increase  users’  ability  to  utilize  all  the 
functions  of  the  DSOR  II  IS  and  minimize  the  risk  of  not  being  able  to  accomplish  the  mission  if 
one  person  is  unavailable.  It  is  recommended  that  the  DSOR  team  hold  45-60  minute  training 
sessions  each  quarter  to  leam  about  any  new  features,  highlight  seldom  used  features,  and  cross 
train  on  other  tasks. 

Implement  feedback  &  continuous  improvement  methods 

It  is  important  to  focus  on  continually  improving  the  IS  and  giving  users  the  opportunity 
to  provide  feedback.  The  organization  must  communicate  the  importance  of  making  the  system 
user  friendly  and  promote  its  feedback  channels.  The  DSOR  II  IS  currently  has  a  good  feedback 
option  through  its  IS  interface.  Based  on  interviews  and  informal  discussions,  users  seldom  use 
this  feature  to  provide  suggestions  for  improvements  or  express  their  complaints. 

The  fact  the  DSOR  team  sought  external  assistance  to  improve  the  effectiveness  of  the 
DSOR  II  IS  is  a  strong  signal  that  it  values  continuous  improvement.  The  project  management 
team  meets  regularly  and  makes  it  a  priority  to  address  any  feedback  it  does  receive  through  the 
feedback  function.  It  would  be  beneficial  to  communicate  the  feedback  function  within  DSOR  II 
so  users  are  more  aware  of  this  option  and  can  contribute  to  improving  the  system. 
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Theories  and  findings  from  the  literature  review  were  used  in  this  chapter  to  evaluate  the 
DSOR II  IS.  The  analysis  determined  how  the  DSOR II  fared  in  comparison  to  industry  best 
practices  and  how  the  DSOR  team  can  make  improvements.  The  findings  from  the  analysis  and 
managerial  implications  from  this  chapter  are  summarized  in  Chapter  5. 
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V.  Findings  &  Conclusion 


This  case  study  explored  IS  deficiencies  hindering  the  activities  of  a  USAF  supply  chain 
stakeholder.  The  literature  review  chapter  identified  theoretical  approaches  to  best  strategize, 
design  and  implement  a  successful  IS.  The  DSOR II  IS  was  evaluated  using  theories  and 
existing  research  found  in  the  literature  review.  A  case  study  approach  was  taken  to  collect 
information,  analyze  the  findings  and  make  recommendations.  The  data  collection  sources 
included  documents,  archival  records,  interviews  and  discussions,  observation,  and  direct 
participation.  The  data  was  then  analyzed  to  identify  any  managerial  implications  in  the  DSOR 
II  project.  The  key  findings  and  managerial  implications  are  summarized  in  the  sections  below. 

Finding  1:  Align  Organizational  &  IS  Strategies 

The  DSOR  team’s  current  customer  is  the  AFMC  community.  Its  processes  are  part  of 
the  USAF  acquisition  system  and  enable  other  stakeholders  to  execute  its  mission.  The  DSOR  II 
IS  is  a  tool  developed  to  help  the  DSOR  team  execute  its  internal  processes.  While  its  internal 
processes  require  input  from  other  stakeholders,  the  DSOR  II  does  not  benefit  other  stakeholders 
directly.  The  DSOR  II  project  team  must  focus  on  incorporating  the  DSOR  team’s  processes 
within  DSOR  II.  Most,  if  not  all,  of  DSOR  II  project  effort  and  resources  should  enable  the 
DSOR  team  to  provide  cost  effective,  timely  and  flexible  logistics  products  and  services  to 
USAF  war-fighters.  The  DSOR  team’s  processes  are  summarized  in  Figure  9.  It  is 
recommended  that  the  project  team  focus  on  incorporating  each  of  the  five  processes  and  its 
infonnation  flow  into  DSOR  II. 
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Finding  2:  Mitigate  Organizational  Capability  Roadblocks 


There  are  two  organizational  capabilities  which  threaten  the  successful  development  and 
implementation  of  the  DSOR II  IS.  The  first  capability  is  process  compatibility.  There  are 
several  issues  which  need  to  be  addressed  before  DSOR  II  can  be  made  a  joint  IS.  The  DSOR  II 
project  team  must  conduct  further  research  to  identify  the  Anny,  Navy  and  Marine  DSOR 
processes  and  align  the  business  process  of  each  service  with  the  DSOR  II  IS.  The  DSOR  II  IS 
in  its  current  form  would  not  be  useful  to  any  other  service. 

The  second  organizational  capability  which  needs  to  be  addressed  is  a  knowledgeable, 
diverse  cross-functional  project  team.  This  team  needs  to  include  stakeholders,  both  internal  and 
external,  to  the  DSOR  II  project  team  to  provide  input  and  identify  user  requirements.  The 
project  team  also  needs  IS  expert(s)  to  assist  the  team  in  identifying  its  technical  requirements 
and  communicating  software  engineering  aspects  of  IS  design  to  the  contractor.  This  expertise 
may  come  from  an  organization  within  AFMC. 

Finding  3:  Incorporate  DSOR  Team  Business  Processes 

DSOR  II  does  not  effectively  capture  the  processes  executed  by  the  DSOR  team  in  its 
workflow  process  function.  There  are  sub-processes  which  are  being  executed  outside  of  DSOR 
II  because  it  does  not  support  the  users’  tasks.  The  DSOR  project  team  needs  to  work  as  a  cross¬ 
functional  team  which  involves  internal  and  external  stakeholders,  USAF  IS  expert(s),  and  the 
contractor  to  incorporate  all  the  DSOR  processes  into  DSOR  II. 
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Finding  4:  Conduct  Business  Process  Re-engineering 


There  is  a  disconnect  in  how  DSOR II  records  DSOR  data  (by  system  or  subsystem)  and 
how  the  rest  of  the  USAF  supply  chain  records  data  (by  NSN).  This  disconnect  makes  it  difficult 
to  search  for  data  in  DSOR  II.  Another  challenge  to  having  different  units  of  record  is  that  DSOR 
II  cannot  exchange  information  with  other  IS.  The  DSOR  II  project  team  needs  to  conduct 
further  research  to  address  feasibility  of  storing  data  in  DSOR  II  by  NSN  instead  of  weapon 
system  or  subsystem.  This  needs  to  be  the  first  step  before  DSOR  II  can  be  interoperable  with 
another  system  such  as  D200A  or  D043A. 

Finding  5:  Address  DSOR  II  Data  Quality  Issues 

The  accuracy,  reliability  and  completeness  of  data  contained  in  the  DSOR  II  database 
function  are  poor.  Data  needs  to  first  be  stored  in  units  which  can  communicate  with  other  IS 
(by  NSN)  and  it  needs  to  be  integrated  with  other  systems  which  contain  reliable  information. 

The  current  process  does  not  allow  for  DSOR  II  to  be  updated  once  there  are  changes  in  the 
sustainment  phase.  Exchanging  data  with  a  primary  supply  chain  IS  such  as  D200A  or  D043A 
would  keep  the  DSOR  II  data  up  to  date  and  reliable.  Integrating  DSOR  II  with  other  systems 
will  require  time  and  funding  to  increase  its  capabilities  and  capacity. 

A  temporary  solution  may  be  to  give  DSOR  users  access  to  D200A.  This  solution  will 
require  DSOR  team  members  to  access  D200A  to  find  information  about  a  part.  DSOR  II  users 
are  currently  search  in  multiple  systems  to  find  part  data.  The  setback  is  that  DSOR  II  becomes 
obsolete  if  users  having  to  search  in  other  databases  for  basic  information  DSOR  II  are  supposed 
to  store. 
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Future  Research 


There  are  several  other  areas  of  research  identified  in  the  course  of  this  study.  The  four 
recommendations  for  future  study  involve  developing  the  findings  of  this  study  and/or 
investigating  potential  issues  identified  in  this  study.  Future  areas  of  research  include  applying 
the  IS  development  framework  to  other  organizations  in  the  USAF  supply  chain,  studying  the 
number  of  IS  utilized  by  each  USAF  supply  chain  stakeholder  in  accomplishing  their  tasks, 
quantifying  the  operational  or  functional  implications  of  a  decentralized  IS  approach  and 
evaluating  how  efficiently  the  DoD  is  using  its  repair  capabilities. 

Apply  framework  to  multiple  case  studies 

This  study  will  put  an  emphasis  on  stakeholders  and  how  they  are  handling  the 
decentralized  management  of  USAF  supply  chain  IS.  It  will  address  if  most  stakeholders  are 
establishing  their  functional  IS  and  detennine  the  impact  that  may  be  having  on  supply  chain 
partners.  This  topic  should  be  applied  numerous  supply  chain  stakeholders  and  essential  turn 
this  thesis  into  a  multiple  case  study.  Applying  the  framework  on  multiple  organizations  will 
help  determine  if  the  findings  in  this  study  is  a  pattern  which  needs  to  be  addressed  by 
leadership.  It  will  provide  insight  into  how  well  or  poorly  orgs  are  managing  the  decentralized 
approach 

Study  USAF  supply  chain  stakeholder  use  of  IS 

This  study  will  put  an  emphasis  on  the  end-user  and  how  the  decentralized  approach 
impacts  him/her.  It  will  identify  how  many  systems  are  being  used  by  program  managers,  item 
managers,  and  war-fighter  in  executing  their  daily  tasks.  This  topic  must  be  designed  to  provide 
insight  into  the  effects  of  the  decentralized  approach  on  process  efficiency.  The  researcher  will 
investigate  whether  the  decentralized  IS  management  approach  is  making  the  USAF  supply 
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chain  more  or  less  efficient.  By  identifying  the  number  of  IS  users  are  required  to  use  and  how 
this  contributes  to  business  process  effectiveness  and  efficiency,  the  research  can  conclude  how 
the  current  IS  system  network  is  impacting  the  USAF  supply  chain  workforce. 

Identify  operational  &  financial  implications  of  decentralized  IS  management 

This  study  will  put  an  emphasis  on  the  amount  of  resources  being  allocated  to  managing 
“local”  IS.  The  research  will  quantify  the  number  of  USAF  supply  chain  stakeholders  with 
locally  managed  IS,  how  much  it  is  spending  on  the  development  and  management  of  the  IS,  and 
whether  the  IS  is  effectively  meeting  its  intent.  It  will  study  whether  the  local  systems  are  truly 
achieving  process  efficiency  and  realizing  a  return  on  investment.  The  objective  of  the  study  will 
be  to  provide  insight  into  the  cost  of  the  decentralized  IS  approach. 

Evaluate  use  of  repair  capabilities  throughout  the  DoD 

This  study  will  put  an  emphasis  on  how  each  DoD  branch  manages  its  repair  capabilities 
It  will  identify  any  redundant  repair  capabilities  throughout  DoD  and  determine  the  feasibility  of 
combining  the  redundant  efforts/resources.  As  a  result,  the  research  will  be  able  to  determine  if 
the  DoD’s  repair  facilities  and  capabilities  are  being  used  efficiently  by  all  of  the  services.  This 
study  may  provide  opportunities  for  cost  reduction  or  increased  efficiency  in  DoD’s  $30B  depot 
maintenance  program. 

Conclusion 

In  today’s  technological  environment,  organizations  rely  on  effective  IS  to  be  competitive 
its  industry.  Many  organizations  rely  on  an  EPR  system  or  an  effective  IS  network  to  realize  the 
benefits  of  available  technology.  However,  there  are  organizations  which  have  not  been  able  to 
leverage  available  IS  capabilities  at  an  enterprise  level.  This  report  addresses  how  organizations 
can  best  address  the  deficiencies  of  enterprise  level  IS  networks. 
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The  literature  review  helped  create  a  framework  organizations  can  use  to  minimize  the 
negative  impacts  of  the  enterprise-level  IS  deficiencies.  The  framework  was  used  to  evaluate 
USAF  DSOR  team  and  found  five  key  managerial  implications  which  will  make  its  IS  more 
effective  and  efficient.  The  framework  developed  in  this  report  can  be  used  to  improve  the  IS 
effectiveness  of  any  organization  challenged  with  enterprise-level  IS  deficiencies  until  those 
deficiencies  are  addressed. 
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Appendix  1:  Example  of  Organizational  and  IS  Strategy  Set 


Organizational 

Information  System 

to  increase  earnings  by  10%  per  year 

to  improve  speed  of  billing 

to  improve  cash  flow 

to  provide  information  on  product  failures 

to  maintain  a  high  level  of  customer  good 

will 

to  provide  information  on  new  business 
opportunities 

to  be  perceived  as  socially  responsible 

<  Objectives  > 

to  provide  information  which  will  permit 
the  assessment  of  the  level  of 
organizational  objectives 

to  produce  high  quality,  safe  products 

to  provide  timely  and  accurate  information 
on  recent  performance 

to  eliminate  vulnerability  to  the  business 
cycle 

to  produce  reports  desired  by  regulatory 
agencies 

to  produce  information  which  will  permit 
quick  response  to  customer  inquiries 

diversification  into  new  businesses 

Design  on  modular  basis 

improvements  in  credit  practices 

modular  design  must  produce  viable 
system  at  each  stage  of  completion 

product  redesign 

<  Strategies  > 

system  must  be  oriented  to  differential 
usage  by  various  classes  of  managers 

system  should  be  responsive  to  the 
perceived  need  of  its  user-managers 

system  should  have  real  time  inquiry 
capability 

highly  sophisticated  management 

Availability  of  funds  for  development  may 
be  reduced 

poor  recent  performance  has  fostered  a 
recognition  of  the  need  for  change 

system  must  incorporate  best  available 
decision  models  and  management 
techniques 

most  managers  are  experienced  users  of 
computer  services 

<  Attributes 
Constraints  > 

System  must  incorporate  environmental 
information  as  well  as  internal  information 

high  degree  of  decentralization  of 
management  authority 

System  must  provide  for  different  reports 
involving  various  levels  of  aggregation 

organization  must  be  response  to  regulatory 
agencies 

System  must  be  capable  of  producing 
information  other  than  management 
information 

70 


Appendix  2:  DoD  Acquisition  System  Process  Map 


Production  &  Deployment  Phase 


Joint  ! 
Capabilities 
Integration  & 
Development 
System 

(nsed-dtiven) 


Evolutionary  Acquisition  Strategy 

xfigggasfggE 


Oversight 


Review 


Contracting 


Major 

Products 


Reprertentativo 


Production 


Production 


Logistics/ 

Sustainment 


Defense 

Acquisition 

System 

(event-driven) 


Technical 


Financial 

Management 


HE3E3E3 


Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  System 


£AU 


Following  I  he  Materiel  Development  Decision,  the  Milestone  Decision  Authority  may  authorize  entry  into  the  acquisition  process  at  any  point,  consistent  with  phase-specltic  entrance  criteria  and  statutory  requirements 
-  Materiel  Solution  Analysis  Phase  — *  • - Technology  Development  Phase  - *  * - Engineering  &  Manufacturing  Development  Phase 


-  Operations  &  Support  Phase  — 
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Appendix  3:  USAF  Organic  Depot  Capability  by  Function 


USAF  Organic  Depot 

TRC  # 

Description 

Oklahoma 

City 

Ogden 

Warner 

Robins 

1 

Weapons 

X 

2 

Air  Munitions  and  Tactical  Missiles 

X 

3 

Electrical  Components 

X 

X 

X 

4 

Electronic  Support  Equipment 

X 

5 

Electro/Mechanical  SE 

X 

6 

Airborne  Electronics 

X 

7 

C41 

X 

X 

X 

8 

Missile  &  Space  Launch  Vehicle 

Components,  Launch  Control  and  Strategic 
Missiles 

X 

9 

Hydraulics/Pneudraulics/Pneumatics 

X 

X 

X 

10 

Oxy  &  Other  Gas  Generating  Equip 

X 

11 

Life  Support  Systems 

X 

X 

X 

12 

Nuclear  components 

X 

13 

Propellers 

14 

Shelters 

X 

X 

15 

Landing  Gear 

X 

16 

Photographic/Reconnaissance 

Imaging  Equipment 

X 

17 

Training  &  Simulation  Equipment 

X 

18 

Instruments/Displays 

X 

X 

X 

19 

Airframe/Aircraft  Related 

X 

X 

X 

20 

Engines/Engine  Related 

X 

X 

21 

Composites, 

Plastics,  Rubber,  &  Metal  Bonding 

Moved  to  TRC  19 

22 

Cryptologic,  Signal  Intelligence  systems, 

Force  Protect,  and  Information  Warfare 
Product 

Crypto  -  CPSG 

23 

Software 

X 

X 

X 

24 

Reclamation 

AMARG 
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Appendix  4:  IRB  Exemption  Approval 


DEPARTMENT  OF  THE  AIR  FORCE 
AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 
WRIGHT-PATTERSON  AIR  FORCE  BASE  OHIO 


27  October  2014 


MEMORANDUM  FOR  DR.  MATTHEW  DOUGLAS 

FROM:  Jeffrey  A.  Ogden,  PhD. 

AFIT  IRB  Research  Reviewer 
2950  Hobson  Way 

Wnght-Patterson  AFB,  OH  45433-7765 

SUBJECT:  Approval  for  exemption  request  from  human  experimentation  requirements  (32  CFR 
219,  DoDD  3216.2  and  AFI 40-402)  for  the  AFMC  A4  Depot  Source  of  Repair  Research 

1.  Your  request  was  based  on  the  Code  of  Federal  Regulations,  title  32,  part  219,  section  101, 
paragraph  (b)  (2)  Research  activities  that  mvolve  the  use  of  educational  tests  (cognitive, 
diagnostic,  aptitude,  achievement),  survey  procedures,  interview'  procedures,  or  observation  of 
public  behavior  unless:  (i)  Information  obtained  is  recorded  m  such  a  maimer  that  human 
subjects  can  be  identified,  directly  or  through  identifiers  linked  to  the  subjects;  and  (ii)  Any 
disclosure  of  the  human  subjects’  responses  outside  the  research  could  reasonably  place  the 
subjects  at  risk  of  criminal  or  civil  liability'  or  be  damaging  to  the  subjects’  financial  standing, 
employability,  or  reputation. 

2.  Your  study  qualifies  for  this  exemption  because  you  are  not  collecting  and  reporting  sensitive 
data,  w'lnch  could  reasonably  damage  the  subjects’  financial  standing,  employability,  or 
reputation.  Further,  you  are  not  collecting  and  reporting  any  demographic  data  wfrich  could 
realistically  be  expected  to  map  a  given  response  to  a  specific  subject. 

3.  This  determination  pertains  only  to  the  Federal,  Department  of  Defense,  and  Air  Force 
regulations  that  govern  the  use  of  human  subjects  m  research.  Further,  if  a  subject’s  future 
response  reasonably  places  them  at  risk  of  criminal  or  civil  liability  or  is  damaging  to  their 
financial  standing,  employability,  or  reputation,  you  are  required  to  file  an  adverse  event  report 
writh  this  office  immediately. 


10/27/2014 


Jeffrey  A.  Ogden 


Jeffrey  A.  Ogden,  Pti.D. 

IRB  Exenrpt  Detenrination  Official 
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Appendix  5:  Consent  to  Participate  in  Interview 
CONSENT  TO  PARTICIPATE  IN INTERVIEW 


DEPOT  SOURCE  OF  REP.UR  (DSORj  DATA  SLiXiGESIEST RESE.iF.CH 

You  have  been  asked  to  participate  m  a  research  study  conducted  by  Capt  Dipta  Kata  from  the  School  of 
Engineering  and  Management  at  the  Air  Force  Institute  ofTechnoIogv  (AFTT).  The  purpose  of  the  study  is  to 
research  and  address  inconsistencies  with  DSOE  data  in  mulnple  information  systems  (IS)  in  use  by  stakeholders  in 
the  logistics  supply  chain  The  results  of  this  study  will  be  included  in  Capt  KazTs  Master's  thesis.  You  were 
selected  as  a  possible  participant  in  this  study  because  of  your  knowledge  with  the  Air  Force  acquisition  and  DSOR 
process  You  should  read  the  infoimanon  below,  and  ask  questions  about  anything  you  do  not  understand,  before 
deciding  whether  or  not  to  participate. 

•  This  interview  is  voluntary.  You  hate  the  right  not  to  answer  any  question,  and  to  stop  die  interview  at  any  tune  or 
for  any  reason  I  expect  that  the  interview  will  take  about  60  minutes 


•  You  will  not  be  compensated  for  this  interview. 


•  The  information  you  tell  us  will  be  confidential 

•  I  would  like  to  record  notes  of  tins  interview  in  a  word  document  so  that  I  can  use  it  for  reference  while  proceeding 
with  this  study.  I  will  not  record  this  interview  without  your  permission  If  you  do  grant  permission  for  this 
conversation  to  be  typed,  you  have  the  nght  to  revoke  permission  and  or  end  the  inteiview  at  any  time. 


This  project  will  be  completed  by  April  2015.  All  interview  documents  will  be  stored  m  a  secure  work  space  until  1 
year  after  that  date.  The  documents  will  then  be  destroyed. 

I  understand  the  procedures  described  above.  My  questions  have  been  answered  to  my  satisfaction  and  I  agree  to 
participate  in  this  study.  I  have  been  given  a  copy  of  this  form. 


(Please  initial) 


0  I  give  permission  for  tins  interview  to  be  recorded  in  a  word  document. 


Name  of  Subject 


Signature  of  Subject 


Date 


Signature  of  Investigator 


Date 


Please  contact  Capt  Kazi  with  any  questions  or  concerns  at 


Captain  Kazi.  Dipta  AHT  ENS  DSN875-3636  DK  9  Oct  2014 
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Appendix  6:  Research  Summary  Provided  to  Interview  Subjects 

TALKING  PAPER 
ON 

DEPOT  SOURCE  OF  REPAIR  (DSOR)  DATA  MANAGEMENT  RESEARCH 

-  The  purpose  of  this  talking  paper  is  to  introduce  an  HQ  Air  Force  Materiel  Command  (AFMC) 
A4D  sponsored  study  being  conducted  by  the  Air  Force  Institute  of  Technology  (AFIT)  to 
research  and  address  inconsistencies  with  DSOR  data  in  multiple  infonnation  systems  (IS)  in 
use  by  stakeholders  in  the  logistics  supply  chain 

-  Issue  /  Research  Problem  Statement 

—  The  DSOR  location  for  reparable  Air  Force  parts  is  inconsistent  among  select  Air 
Force  &  DoD  logistics  infonnation  systems 

—  Infonnation  systems  being  studied  include  (1)  DSOR  II  Sharepoint,  (2)  DSOR  Depository, 
(3)  Federal  Logistics  Information  System  Web  Search  (WebFLIS),  (4)  Logistics,  Installations, 
and  Mission  Support  -  Enterprise  View  (LIMS-EV),  (5)  Enterprise  Solution  Supply  (ES-S),  (6) 
D043A  Master  Item  Identification  Database,  (7)  D035A  Stock  Control  &  Wholesale 
Distribution  Database  (more  IS  may  be  added  as  research  progresses) 

-  Research  Objectives 

—  Identify  the  extent  of  the  DSOR  data  inconsistencies  among  the  various  infonnation 
systems 

—  Quantify  the  impact  of  DSOR  data  inconsistencies  on  Air  Force  resources 
—  Deliver  actionable  steps  to  AFMC  A4D  to  minimize  the  impact  of  data  inconsistencies 

-  Research  Methodologies 

—  Interviews  with  acquisition  stakeholders,  subject  matter  experts,  managers,  and  more 


—  Case  study  of  Air  Force  parts  (by  NSN)  and  the  IS  in  use  by  different  stakeholders 


—  Literature  review  of  journal  articles,  Air  Force  Instructions,  manuals,  and  more 
-  Points  of  Contact 

—  Researcher,  Capt  Dipta  Kazi,  AFIT  Masters  Student,  School  of  Logistics  &  Management 

—  Research  Advisor,  Dr.  Alan  Johnson,  AFIT  Faculty,  School  of  Logistics  &  Management 
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Appendix  7:  Sample  Interview  Questions 


Below  are  some  sample  questions  that  were  used  to  guide  one  of  the  interviews  with  an 
acquisition  program  manager: 

1 .  What  is  the  next  process  once  DSOR  memo  is  signed  and  returned  to  your  program 
office? 

a.  Is  there  a  working  group  that  takes  place  between  the  program  office  and 
depot  to  stand  up  the  repair  capability? 

b.  If  there  is  a  working  group,  do  you  have  meeting  minutes  from  previous 
projects? 

2.  What  IT  system(s)  do  you  use  to  manage  acquisition  projects?  Are  you  able  to  help 
me  obtain  basic  viewing  access? 

3.  Do  you  know  who  finalizes  the  DSOR  location  and  inputs  it  into  a  system  of  record 
(perhaps  D043A,  LIME-EV,  or  other  system)? 

4.  Do  you  work  directly  with  anyone  at  the  depots?  If  so,  what  is  your  interaction  with 
them? 

5.  What  are  your  biggest  challenges  in  working  with  different  stakeholders  (HQ 
AFMC,  depots,  other  program  offices,  contractors,  etc)? 

a.  Can  these  challenges  be  minimized  with  more  streamline  infonnation 
technology? 

b.  What  are  some  best  practices  you’ve  seen  in  managing  projects  that  you 
would  implement  throughout  the  supply  chain? 
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Appendix  8:  List  of  NSNs  Researched 


Nat.  Stock  Number  (NSN) 

Part  Description 

F-16 

1660014733547 

Concentrator  (CGU-24/A) 

1660014733549 

Regulator  (CRU-98/A) 

5895014977131 

Interrogator/Transponder  Set 

5895014419089 

Beam  Forming  Network 

011216879 

Stores  Control  Panel 

012630648 

Pilot  Controller  Grip  Assembly 

1270014665918 

Processor,  Radar  Data 

010618335 

Flydrive  Gun  System 

5  84001 56757 16CY 

TRAN  SPONDER, RADAR 

4810013631952WF  (XB3) 

VALVE, REGULATING, FL 

1650012289276 

DRIVE, CONSTANT  SPEE 

6 13001 5228349 WF  (XF3) 

POWER  SUPPLY  ASSEMB 

62200 14433629WF  (XF3) 

LIGHT, NAVIGATIONAL, 

|  C-130  | 

014522467 

Control,  Generator 

014771973 

Anti-Skid  Test  Set 

5821014833248 

Radio 

1 62000805 8495LE 

TORQUE  STRUT  ASSEMBLY, LANDING  GEAR 

6610014873794LG 

DISPLAY  UNIT, FLIGHT  INFORMATION 

5841014708036CX 

PROCESSOR, RADAR  DATA 

28400104911530J 

LINER, COMBUSTION  CHAMBER, AIRCRAFT  GAS  TU 

6610015272395 

INDICATOR,  VERTICAL 

1610008736424 

AFTER  BODY  HALF  BODY 

1620011708325 

CYLINDER  AND  PISTON  ASSEMBLY, LANDING  GEA 

F-22 

5985015260321 

Antenna 

1560015246083 

Radome 

5993015237903 

Generator/ Amplifier 

6130014869149 

Power  Supply 

5841015279740 

Processor,  Radar  Data 

2840015614467RF 

LINER, AFT  EXT  SW  UR 

1560015252952FR 

DOOR, ACCESS, AIRCRAF 

2915014869732FR 

REGULATOR, FUEL  FLOW 

2840015466641RF 

LINER, TURBINE  COMPO 

6150015489029FR 

WIRING  HARNESS 

C-17 

2915013576590BE 

FUEL  CONTROL, MAIN, T 

5998014076273 

ELECTRONIC  COMPONENTS  ASSEMBLY 

1680014353302 

Hydraulic  Mechanical  Linear  Actuator 

1680014580365 

PANEL, CONTROL, ELECTRICAL-ELECTRONIC  EQUI 

6680015458956 

TRANSMITTER,  MJP 

6115015444400 

GENERATOR,  IDG 

1680014497704 

ACTUATOR,  ELECTRO-ME 

4310015138110 

OBIGGS  1.1  COMPRESSOR 

2835013590360 

POWER  UNIT,  APU 

6130015935699 

CHARGER,  BATTERY 

5865015796300 

TRANSMITTER,  COUNTER 

5821014764092 

RT  IN  MARSAT 
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Appendix  9:  Thesis  Storyboard 


Addressing  Enterprise-Level 
Information  System  Deficiencies 


Capt  Dipta  Kazi 


Introduction 

The  failure  of  the  United  States  Air  Force's 
(USAF)  Expeditionary  Combat  Support  System 
(ECSS)  program  has  resulted  in  supply  chain 
stakeholders  creating  independent  solutions  in 
a  complex  network  of  supply  chain  information 
systems  (IS).  The  decentralized  management  of 
IS  has  led  to  stakeholders  optimizing  local 
missions  to  the  detriment  of  enterprise  level 
goals  and  effectiveness.  This  case  study 
evaluates  the  Depot  Source  of  Repair  (DSOR) 
team  and  how  it  has  addressed  the  USAF's 
enterprise-level  IS  deficiencies.  A  framework 
created  from  the  literature  review  is  used  to 
evaluate  the  DSOR  team's  IS  called  DSOR  II. 
The  case  study  evaluation  identified  five  key 
managerial  implications  which  better 
addresses  the  negative  impacts  of  USAF  IS 
deficiencies.  A  more  effective  IS  will  help  the 
DSOR  team  manage  the  USAF's  $13  billion 
depot  repair  program  more  effectively.  The 
framework  introduced  in  this  report  can  be 
used  by  organizations  challenged  with 
enterprise-level  IS  deficiencies. 


Problem  Statement 

•  Decentralized  IS  approach  led  to  sub¬ 
organizations  creating  IS  solutions  which 
optimize  local  missions 

•  ‘‘Pocket  optimization’'  results  in  sub-optimal 
IS  solutions  for  supply  chain  partners 

•  Sub-organization’s  lack  of  strategic  outlook, 
process  knowledge  and  resources  lead  to 
expensive,  inefficient  and  sub-optimal  supply 
chain  IS  network 


Co-Advisors: 

Dr.  Alan  W.  Johnson 
Lt  Col  Matthew  A.  Douglas 

Research  &  Investigative  Questions 

Research  Question:  How  can  organizations  address  negative  impacts  of 
enterprise-level  Information  System  (IS)  deficiencies? 

Investigative  Questions  (IQ): 

1.  How  does  an  organization  evaluate  and  identify  the  requirements  of  an 
effective  Information  System  (IS)? 

2.  How  does  an  organization  design  an  IS  which  best  serves  its  intended 
function? 

3.  How  does  an  organization  adopt  and  implement  an  IS? 


Literature  Review  /  Framework 

The  literature  review  identified  existing  research  and  theories  on  IS  strategy, 
design  and  diffusion.  Its  purpose  is  to  offer  a  solution  to  minimizing  the 
challenge  of  working  in  an  enterprise  which  employs  a  decentralized  IS 
approach.  The  findings  in  the  literature  review  can  be  summarized  in  the 
framework  presented  below. 
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Methodology 

•  Single  Case  Study:  Depot  Source  of  Repair 
Team  (DSOR) 

-  Evaluate  DSOR  team  IS  using  theories  & 
existing  research  developed  in  literature 
review 

•  Purpose:  Address  IS  deficiencies  from 
supply  chain  stakeholder  perspective 

•  Literature  review:  Existing  theories  & 
research  on  IS  strategy,  design  and  diffusion 

•  Data  Collection:  documents.  archival 
records,  interviews,  direct  observation, 
participant  observation 

•  Analysis:  used  framework  to  analyze  case 
study  data 


Managerial  Implications 

1.  Align  organizational  &  IS  strategies 
Focus  on  making  DSOR  II  an  effective 
tool  for  DSOR  team 

2.  Address  organizational  capability 
roadblocks 

Use  cross-functional  team  to  manage 
DSOR  II  project 

3.  Reduce  stakeholder  complexity 

Incorporate  all  DSOR  team  processes 
into  DSOR  II 

4.  Re-engineer  Business  Process 

Change  business  process  to  record  data 
by  NSN 

5.  Achieve  IS  interoperability 

Set  up  electronic  data  exchange 
capability  with  D200A 


Research  Sponsor 

Air  Force  Materiel  Command  (AFMC) 
Wright  Patterson  AFB.  Ohio 
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framework  introduced  in  this  report  can  be  used  by  organizations  challenged  with  enterprise-level  IS  deficiencies. 
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